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The  languages  people  use  to  communicate 
with  computers  differ  in  their  intended  apti- 
tudes, towards  either  a  particular  application 
area j  or  a  particular  phase  of  computer  use 
(high  level  programming,  program  assembly,  job 
scheduling,  etc*).   They  also  differ  in  physi- 
cal appearance a  and  more  important  in  logical 
structure.   The  question  arises,  do  the  idio- 
syncrasic  :<  reflect  basic  logical  properties  of 
the  situations  that  are  being  catered  for? 
(La66,  p.  164). 


CHAPTER  1 
SYSTEM  STRUCTURES 

Intro duct ion 

The  last  decade  has  produced  many  areas  of  interest 
within  the  field  of  computer  science.   This  thesis  is  con- 
cerned with  the  subarea  of  computer  systems,  and  more 
specifically  the  virtual  design  (abstracted  from  any  par- 
ticular physical  hardware)  for  networks  of  asynchronously 
operating  digital  computers.   In  addition  to  being  appro- 
priate for  networks,  the  general  design  presented  in  this 
thesis  can  be  used  to  describe  current  logical  operating 
systems  and  can  provide  a  framework  within  which  to  design 
languages. 

Early  digital  computers  were  very  simple,  had  only 
limited  structures  within  which  users  could  formulate 
solutions  to  their  problems,  interpreted  only  simple 


sequences  of  instructions,  and  were  under  the  complete  con- 
trol of  one  user  at  a  time.   Input  and  output  was  normally 
under  user  program  control,  and  only  minimal  control  func- 
tions were  provided  such  as  test  and  skip  en  certain  flags, 
limited  jumps,  and  instruction  modification. 

Users  soon  desired  to  construct  more  complex  compu- 
tations.  More  general  control  structures  were  introduced 
along  with  ways  of  communicating  between  program  parts. 
Extended  machine  languages  were  developed  to  exploit  these 
new  features.   Users  could  now  do  more,  and  they  soon 
found  that  such  tasks  as  the  routine  testing  for  external 
interactions,  were  wasting  much  of  their  capacity.   The 
resulting  concept  of  interrupt,  which  was  "apparently  in- 
troduced with  the  UNIVAC  110  3"  to  obtain  good  input/output 
(BN7D  did  away  with  this  annoyance  but  introduced  a  more 
complicated  control  structure.   A  well-defined  program 
organization  was  required  so  the  users  could  cause  the 
processor  to  focus  its  attention  on  the  appropriate  pro- 
gram part  at  the  appropriate  time,  along  with  methods  of 
resolving  logical  conflicts  due  to  the  asynchronous  ar- 
rivals of  these  interrupts. 

The  need  to  improve  system  performance  and  lower 
job  costs  by  using  parallelism,  in  conjunction  with  the 
interrupt,  resulted  in  multiprocessor  computer  systems. 
The  use  of  simple  I/O  processors  caused  the  CPU  to  be 


poorly  utilized  when  only  one  user  program  was  resident 
in  the  machine  at  a  time.   Better  CPU  usage  was  achieved 
with  multiprogramming  operating  systems  (time  multiplexed 
programs  proceeding  in  a  pseudo  parallel  manner).   The 
concept  of  digital  "process"  as  a  sequence  of  process 
states  was  developed  as  the  abstraction  of  these  inter- 
acting entities.   Early  processes  were  not  very  complex, 
and  although  each  process  could  proceed  in  pseudo  par- 
allel with  other  processes,  little  or  no  explicit  inter- 
process interactions  were  allowed.   As  users  became  more 
sophisticated,  more  complex  intraprocess  state  structures 
and  control  operations  were  developed.   The  process  state 
normally  includes  both  information  to  direct  the  processor 
in  its  operations  and  the  Information  which  the  processor 
manipulates  in  response  to  such  directions. 

The  ability  to  create  multiple  processes  soon  led 
to  a  desire  to  use  a  set  of  parallel  processes  to  accom- 
plish a  single  purpose  thus  requiring  the  support  of  more 
general  interprocess  interactions.   New  problems  were  cre- 
ated by  multiprocess  systems  because  of  the  need  to  share 
resources.   The  physical  system  needed  to  multiplex  its 
physical  assets  to  achieve  some  optimal  goal,  while  the 
logical  processes  needed  to  share  logical  resources  (for 
example,  the  information  in  files)  amongst  themselves 
while  protecting  these  objects  against  misuse  by  a  bor- 
rower. 
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As  experimentation  with  interprocess  and  system 
user  relationships  proceeded,  a  need  developed  for  the 
management  of  uncooperative  processes.   If  a  user  process 
is  completely  isolated  from  all  other  processes  including 
the  system,  as  was  true  in  earlier  operating  systems ,  it 
can  be  uncooperative  and  only  ths  user  of  that  process  is 
affected.   Such  isolation  is  no  longer  feasible  because 
of  the  diverse  user  population  which  must  now  be  served. 
Many  systems  being  developed  are  attempting  to  fulfill 
these  needs  by  permitting  a  use:1  to  construct  multiprocess 
computations  and  allowing  substantial  interprocess  inter- 
actions including  the  control  of  other  processes. 

The  design  of  a  computer  system  to  support  a  gen- 
eral user  community  can  make  no  simplifying  assumptions 
concerning  their  reliability.   It  must  allow  for  users  who 
are  subject  to  making  errors  and  who  may  even  intention- 
ally try  to  circumvent  the  system  to  achieve  their  own 
goals.  One   of  the  essential  concerns  when  designing  a 
general  purpose  system  is  that  it  be  able  to  support  such 
potentially  uncooperative  processes  while  guaranteeing 
the  integrity  of  the  system.   As  users  employ  more  com- 
plex interprocess  interactions,  they  require  access  to 
more  complex  facilities. 

The  delegation  of  such  services  and  decisions  to 
the  user  process  opens  the  way  for  the  possibility  of 
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significant  uncooperative  behavior  which  the  system  can 
no  longer  prevent.   In  order  to  prevent  such  behavior, 
the  system  designer  would  have  to  make  arbitrary  a  priori 
decisions  as  to  what  is  to  be  considered  uncooperative  be- 
havior by  all  of  the  processes  to  run  on   that  system.   How- 
ever, if  interprocess  interactions  are  permitted,  only  the 
users  of  the  system  (through  their  processes)  can  decide, 
in  general,  when  uncooperative  behavior  has  occurred  with 
respect  to  these  interactions.   It  is  impossible  for  the 
system  to  prevent  uncooperative  process  behavior  without 
imposing  worse  case  restrictions  on  all  processes. 

The  real  need  is  to  control  the  effects  of  such 
uncooperative  behavior  by  regulating  the  scope  of  the 
effects  of  the  interprocess  interactions  of  each  process. 
If  one  process  within  a  system  claims  another  is  being  un- 
fair, either  some  outside  authority  must  arbitrate  or  they 
must  come  to  a  joint  solution,  in  which  case  they  have 
implicitly  formed  a  joint  authority.   A  generalization  of 
the  system/user  relationship  is  necessary  if  a  network  de- 
sign is  to  permit  delegation  of  the  control  of  interesting 
interprocess  interactions.   Users  must  be  delegated  the 
authority  to  control  the  processes  over  which  they  have 
responsibility.   For  example,  a  user  process  should  have 
the  same  ability  to  control  the  processes  it  creates,  as 
a  time  sharing  system  process  has  to  control  the  processes 
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it  has  created  for  users .   Users  must  be  provided  a  me- 
chanism for  exercising  their  authority,  where  the  rules 
of  responsibility  say  it  is  appropriate ,  thus  permitting 
them  to  control  the  interactions  of  those  processes  which 
they  feel  need  be  controlled.   At  the  same  time  though, 
those  processes  not  under  their  responsibility,  must  be 
provided  protection  from  their  authority. 

One  final  need  becoming  apparent  today  is  for  sys- 
tem designs  to  be  portable.   P.  C.  V/ithington  (Wi72)  makes 
some  interesting  observations  about  future  computer  sys- 
tems.  He  claims  that  because  there  will  be  significant 
hardware  cost  performance  improvements  in  the  near  future, 
machine  independent  applications  which  are  portable  will 
be  more  economical  than  "optimized"  machine  dependent 
applications.   Application  systems  would  not  need  to  be 
rewritten  solely  because  the  physical  hardware  upon  which 
they  are  implemented  is  changed.   He  predicts  that  the 
next  generation  will  include  network  systems  and  then 
forecasts  that 

the  operating  system  will  permit  the  network 
of  processing  modules  to  be  widely  varied; 
the  user  will  be  able  to  add,  subtract,  and 
upgrade  them  individually,  without  undergoing 
the  pain  of  conversion.   The  •generation  cycle' 
we  have  become  familiar  with  should  end,  and 
orderly  evolution  should  become  the  rule. 

Today's  software  systems  are  very  complex  and  can- 
not be  rewritten  easily  for  a  new  hardware  system.   If 
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Withingtcn's  predictions  are  correct,  the  benefits  of 
writing  everything  for  a  virtual  (not  machine  dependent) 
system  structure,  and  then  implementing  this  structure  on 
new  physical  devices  would  far  outweigh  the  inefficiencies 
due  to  any  specific  implementation  of  that  virtual  system. 
The  implementer  of  such  a  virtual  system  could  use  trans- 
lation, or  Waite's  macros  (Ua70),  to  ease  the  implementa- 
tion job,  but  the  user  would  not  have  to  be  concerned  with 
the  move.   If  the  virtual  system  is  augmentable,  to  meet 
special  needs,  users  may  be  able  to  gain  some  of  the  same 
efficiencies  they  now  geb  by  writing  for  a  particular  phy- 
sical machine  while  still  getting  portability. 

In  order  for  portability  to  be  successful,  a  clear 
distinction  must  always  be  made  between  the  virtual  struc- 
tures defined  and  the  physical  implementation  of  them. 
The  general  acceptance  of  virtual  address  spaces  and  vir- 
tual processors  has  proven  that  it  is  not  necessary  to  re- 
quire the  logical  and  physical  mapping  to  be  1-1.   A  gen- 
eral design,  that  clearly  separates  the  logical  and  phy- 
sical systems,  is  necessary  if  portability  is  to  be 
achieved.   Only  then  does  the  design  not  become  con- 
strained to  a  particular  type  of  machine  (perhaps  at  the 
cost  of  sacrificing  some  specific  efficiencies  of  each 
machine) . 

With  the  advent  of  networks,  composed  of  different 
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kinds  of  digital  computers,  transportability  becomes  even 
more  imperative.   If  the  complex  is  to  be  a  useful  vehicle 
for  sharing  resources,  then  the  whole  network  must  provide 
a  consistent  face  to  the  user.   Even  if  all  of  the  communi- 
cation interfaces  are  the  same,  the  users  will  be  reluctant 
to  exploit  the  network  if  they  must  interface  with  a  dif- 
ferent operating  system  at  each  node.   A  user  may  wish  to 
move  a  process  between  nodes.   This  means  a  standard  inter- 
face must  be  defined  for  user  processes,  at  a  level  which 
assume  no  particular  physical  architecture  or  devices. 
The  virtual  system  designer  should  not  define  what  par- 
ticular physical  resources  the  implementer  must  have.   The 
implementers  of   the  virtual  system  must  be  given  the  flexi- 
bility to  select  those  physical  resources  which  permit  them 
to  optimize  their  implementation  subject  only  to  local  man- 
agement constraints.   If  hardware  is  developed  which  will 
improve  their  implementation,  they  should  be  able  to  use 
it  without  requiring  any  change  in  the  logical  system  the 
user  sees.   The  only  effect  on  the  user  should  be  a  change 
in  the  cost  performance. 

Current  Work 

Since  it  is  impossible  to  discuss  all  of  the  litera- 
ture relevant  to  this  thesis,  attention  will  be  focused 
primarily  on  those  systems  which  represent  the  logical 
structure  within  which  users  define  their  problems  and 


not  physical  implementation  or  application  problems.   Since 
the  COSINE  report  (Co7D  contains  a  general  discussion  of 
the  area  of  operating  systems  and  provides  an  introduction 
to  many  of  the  terms  that  will  be  used  in  this  review  of 
current  work,  no  real  effort  will  be  made  to  define  speci- 
fic terms  here,   Those  terms  which  are  used  in  later  chap- 
ters will  be  explained  and  defined  at  that  time  within  the 
context  of  the  network  being  developed. 

Of  primary  interest  in  this  thesis  are  those  works 
which  deal  with  networks  of  digital  computers,  the  process 
state  structures  supported  by  systems,  and  the  operating 
environment  provided  for  user  processes.   This  includes 
the  concepts  of  control  and  parallelism,  the  interactions 
among  processes,  and  the  ability  of  a  user  process  to  man- 
age resources.   Papers  dealing  with  the  protection  and  al- 
location of  logical  resources  and  with  portable  systems 
are  also  of  interest.   The  remainder  of  this  section  will 
attempt  to  survey  some  of  these  areas  to  indicate  the  logi- 
cal structures  currently  being  used. 

Networks :   Networks  of  general  purpose  digital  com- 
puters are  becoming  accepted  as  a  viable  way  to  provide 
computer  services,  and  interest  has  developed  in  how  to 
exploit  such  networks  to  allow  increased  availability  of 
physical  and  logical  resources.   Farber  (Fa72)  defines  a 
computer  network  as  "an  interconnected  set  of  dependent 
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or  independent  computer  systems  which  communicate  with 
each  other  in  order  to  share  certain  resources  such  as 
programs  or  data  and/or  for  load  sharing  and  reliability 
reasons*" 

The  April  1972  Datamation  from  which  the  above 
quote  was  taken  provides  a  brief  introduction  to  seven 
"typical  networks"  and  some  of  the  problems  involved  in- 
cluding organization  and  management  of  such  networks. 
Farber's  article  discusses  the  networks  with  respect  to 
organization,  composition,  number  and  geography  of  nodes, 
machine  sizes,,  and  communication  interfaces.   Companion 
art.1c.les  by  Stefferud  (St 72)  and.  Hootman  (Ho72)  look  at 
networks  from  a  manager's  point  of  view,  including  such 
questions  as  "who  is  management,"  "where  it  resides,"  and 
network  economics.   None  of  the  articles  discuss  what 
operating  system  structures  must  be  provided  in  a  network 
to  fulfill  these  responsibilities,  and  none  of  them  make  a 
clear  distinction  between  the  physical  systems  and  the 
logical  systems  which  will  be  using  the  network.   Imple- 
mentation management  problems  relating  to  the  accounting 
of  physical  assets  is  included,  but  not  how  the  logical 
processes  will  be  able  to  manage  logical  resources  dis- 
tributed over  the  network.   The  desire  of  users  to  create 
multiprocess  computations  and  manage  logical  resources  by 
user  defined  techniques  is  being  overlooked,  even  though 
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it  appears  this  may  be  desired  more  in  a  network  than  in 
current  systems.  Although  the  technical  interconnection 
problems  "shov;  promise  of  being  solved"  (St72),  the  pro- 
blems of  how  to  u.se  networks,  and  the  political  and  man- 
agement problems,  must  also  be  solved  before  a  user  will 
be  able  to  write  interesting  and  useful  general  systems 
which  can  exploit  networks. 

Information  concerning  the  "ARPA"  network  is  the 
most  readily  available.   Two  series  of  papers  (CC70SHK70. 
RW70)  and  (CH72,OH72 ,TH72 ) ,  along  with  some  companion 
papers,  provide  a  fairly  complete  discussion  of  it.   The 
purpose  of  ARPANET  was  to  provide  "a  network  that  would 
allow  for  the  interconnection >  via  common-carrier  cir- 
cuits, of  dissimilar  computers  at  widely  separated.  ARPA- 
sponsored  research  centers"  (OH72). 

Each  node  has  an  IMP  (Interface  Message  Processor) 
which  "acts  as  a  nodal  switching  unit  and  also  inter- 
connects the  research  computer  centers"  (HOSTS)  (OH72). 
Originally,  a  user  accessed  the  network  only  through  a 
HOST,  but  it  soon  became  desirable  to  provide  direct 
terminal  access  which  was  done  using  a  Terminal  IMP  (TIP). 
The  TIP  provides  the  services  of  connect  and  disconnect  to 
remote  sites,  and  then  becomes  transparent  to  the  conver- 
sation between  user  and  HOST.   It  is  not  the  intention  of 
this  thesis  to  go  into  the  implementation  problems  of 
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HOST  to  HOST  communication.   The  interested  reader  is  re- 
ferred to  the  papers  for  a  more  complete  description  of 
these  problems. 

"The  growth  of  the  network  has  dynamically  cata- 
lyzed an  area  of  computer  science  which  has  to  do  with 
the  quite  general  problem  of  how  programs  should  inter- 
communicate, whether  in  a  single  computer  or  between  com- 
puters" (01172).   In  the  ARPANET,  an  attempt  was  made  to 
provide  a  general  mechanism  allowing  user-level  process- 
to-process  communication  (CII72).   Interprocess  communica- 
tion is  carried  out  in  a  simplex  manner  using  one  of  the 
256  logical  connections.   Since  each  HOST  in  the  network 
names  its  own  processes,  "sockets"  provide  a  unique  name 
in  a  name  space  divided  among  the  IIOSTs.   Each  HOST  then 
maps  socket  names  onto  the  processes.   Processes  are  cre- 
ated according  to  procedures  local  to  their  respective 
HOSTs,  and  must  interface  with  a  network  control  program 
(NCP)  resident  in  each  HOST  to  be  able  to  communicate.   If 
the  conversation  between  processes  is  to  be  duplex,  two 
connections  must  be  made. 

A  process  uses  local  operating  system  calls  to  tell 
the  NCP  to  send  a  message  to  a  specific  socket.   The  NCP 
interacts  with  the  ARPANET  to  send  the  message  to  the  re- 
ceiver's HOST  NCP,  which  then  uses  appropriate  system 
primitives  to  deliver  the  message  to  the  process  with  the 
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destination  socket.  One  major  weakness  of  the  ARPANET  is 
that  "System  calls  will  vary  from  one  operating  system  to 
another"  (CC70).  The  ARPANET  has  no  concept  of  a  network 
operating  system  it  provides  for  its  processes. 

Pro c ess :   The  use  of  the  term  "process,"  as  a  con- 
cept relevant  to  computer  systems  became  common  in  the 
literature  as  a  result  of  its  use  by  two  separate  groups: 
project  MAC  at  MIT  used  it  in  1964  as  a  "precise  concept 
in  discussing  design  problems  of  mult ip re gramme d  computer 
systems"  (De?0)  and  Dijkstra  used  it  in  196*5  v'tien   he  pub- 
lished his  work  on  "Cooperating  Sequential  Processes" 
(Di67).   It  is  somewhat  surprising  that  the  connotations 
of  the  many  formal  and  informal  definitions  of  process 
are  similar  even  though  each  definition  was  designed  to 
fit  within  a  certain  context.   A  survey  of  these  defini- 
tions can  be  found  in  the  introduction  to  Horning  and 
Randall's  "Process  Structuring"  (HR7D.   Their  definition 
of  process  is  as  follows: 

A  triple  (S,  f,  s),  where  S  is  a  state  vari- 
able set,  f  is  an  action  function  on  that  set, 
and  s  is  the  subset  of  the  state  space  of  S 
which  defines  the  initial  states  of  a  process. 
A  process  generates  all  the  computations  gen- 
erated by  its  action  function  from  its  initial 
states. 

Fitzwater  and  Hintz  (FH71)  present  a  definitional 

system  which  allows  the  designer  to  represent  a  process 

state,  define  a  processor,  and  then  validate  the  design 


by  observing  the  system  behavior  as  the  processor  works 
on  that  state.   Their  definition  of  process  is  an  rinter- 
pretation  sequence  of  process  states,"  This  definitional 
system  is  useful  because  it  relates  processes  to  the  con- 
cepts of  system 8  complexes  of  such  systems,  and  asynchro- 
nous communication  between  the  members  of  this  complex. 
This  system  is  convenient  for  providing  a  formal  defini- 
tion  of  a  design  to  remove  any  ambiguities* 

A  digital  computer  system  has  the  property  that 
there  is  one  or  more  points  in  its  execution  sequence  at 
which  its  state  can  be  observed  and  its  behavior  studied. 
A  process  state  normally  contains  a  process  name  space 
or  data  part,  and  a  program  part  which  directs  a  proces- 
sor in  its  transformation  on  the  process  state. 

Although  the  AHPA  papers  talk  about  creating  a 
process  in  a  HOST  system  and  allowing  processes  in  separ- 
ate HOSTs  to  communicate  using  the  network,  there  is  no 
formalism  of  the  properties  of  a  process  or  of  its  states. 
Each  system  is  controlled  by  the  physical  system  manager 
and  there  are  no  network  operations,  other  than  communi- 
cation, by  which  one  process  can  interact  with  a  process 
in  some  other  system. 

Although  identifiable  processes,  as  components 
in  computer  systems,  were  originally  very  simple,  they 
have  become  more  general  and  more  complex.   Dijkstra 
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(Di65, 67,68,71)  has  investigated  logical  process  coopera- 
tion, when  no  restrictions  exist  on  their  relative  speeds, 
The  cooperating  processes  have  access  to  one  or  more  var- 
iables, which  they  can  cooperatively  check  to  see  whether 
or  not  to  proceed  into  a  "critical  section."  Although  a 
process  may  have  to  wait  logically  on  other  processes  be- 
fore entering  its  critical  section,  it  proceeds  asynchro- 
nously at  all  other  times. 

Numerous  recent  designs  use  the  concept  of  a  pro- 
cess in  describing  their  system.   "THE"  (Di68)  is  a  "so- 
ciety of  sequential  processes  with  undefined  speed  ra- 
tios" where  "harmonious  cooperation  is  regulated  by  means 
of  explicit  synchronizing  statements."  Alsberg's  (A17D 
"OSL/2"  is  an  implementation  of  Dijkstra's  hierarchial 
concepts  in  which  a  process  can  create  and  monitor  new 
processes,  thus  becoming  an  operating  system  for  them. 
"ESOPE"  (BB69)  permits  processes  to  interact  via  inter- 
process communication  and  control  other  processes  by  using 
activate,  block,  create  and  destroy.   "TENEX"  (BB7D  per- 
mits a  user  to  create  a  process  tree  hierarchy  with  mul- 
tiple simultaneously  runnable  processes  where  a  parent 
controls  the  children.   The  "RC^OOO"  system  (Ha7ia)  is 
basically  a  "monitor  that  can  be  extended  with  a  hier- 
archy of  operating  systems."   Any  program  can  initiate 
"other  programs  in  a  hierarchial  manner  and  execute  them 
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according  to  any  strategy  desired,"  In  all  of  these  sys- 
tems j  a.  process  is  normally  considered  as  a  potentially 
asynchronous  executable  entity  with  communication  some- 
times  possible  between  it  and  other  processes  in  the  sys- 
tem. 

Control;   Some  concept  of  control  (what  is  to  be 
done  next)  is  present  in  one  form  or  another  in  all  sys- 
tems and  computer  languages.  When  talking  about  programs 
Dennis  (DV66)  describes  a  "locus  of  control"  and  Denning 
(De68)  a  "thread  of  control."  With  respect  to  multipro- 
gramming and  multiprocessing  systems,  control  may  be  con- 
sidered as  the  switching  of  the  attention  of  the  proces- 
sors among  the  various  programs  in  the  system,  and  can  be 
described  at  various  levels  of  abstraction  (for  example, 
machine  instruction  execution,  program  instruction  se- 
quencing, or  multiprogramming). 

Fisher  (Pi70)  says  "the  control  structure  of  a 
programming  language  is  its  sequencing  or  interpretation 
rules  and  as  such  provides  a  programming  environment  which 
encompasses  any  task  within  that  language."  He  goes  on 
to  say  that  there  is  a  need  for  more  than  a  "step  by  step" 
concept  of  control  so  the  "point  of  view"  with  which  pro- 
blems can  be  attacked  is  not  constrained.   Both  his  intro- 
duction and  that  of  Herriot  (He7D  provide  good  discussions 
of  control. 
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Control  structures  in  most  early  computer  languages 
were  not  much  more  complex  than  the  machines  upon  which 
they  were  designed  to  be  run.   One  instruction  was  se- 
quentially executed  after  another  with  conditionals,  jumps, 
and  later  subroutine  jumps  as  their  only  control  mechanisms. 
Systems  were  normally  dedicated  to  one  user  at  a  time, 
and  it  was  only  to  provide  services  for  the  convenience 
of  the  users  that  a  basic  operating  system  was  developed. 
Although  operating  system  designers  soon  included  concepts 
of  system/user  relationships,  multiprogramming,  and 
multiprocessing,  there  was  little  development  of  languages 
containing  such  concepts. 

SIMULA  (DN67)  introduced  the  concept  of  coroutine 
and  SIMULA  67  (DM68)  extended  this  to  "quasi-parallel  sys- 
tems,"  Nested  blocks  similar  to  SIMULA  main  blocks  were 
allowed,  resulting  in  a  tree  of  nested  coroutines.   "Task- 
master" (FM65a,  FM65b)  (a  real  time  system)  similarly  or- 
ganizes its  tasks  in  a  tree  structure.   Every  Taskmaster 
task  has  several  ALGOL  like  statements  which  may  receive 
control  directly  from  the  scheduler,  or  as  a  result  of 
clock  or  outside  interrupts,  rather  than  sequentially  from 
other  tasks.   A  significant  disadvantage  of  "Taskmaster" 
is  the  requirement  that  all  users  cooperatively  return 
control  to  the  scheduler  before  the  next  task  can  be  exe- 
cuted. 
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Dijkstra's  work  with  cooperating  sequential  pro- 
cesses has  interested  researchers  in  the  definition  and 
implementation  of  systems  permitting  process  interactions, 
along  with  the  associated  problems  of  mutual  exclusion  and 
synchronization.   The  implementation  of  "P&V"  type  opera- 
tions usually  is  based  on  having  only  one   physical  pro- 
cessor or  a  sharable  memory  (OSL/2  (A171),  ESOPE  (BB69), 
OREGAITO  (BE71)S  THE  (Di68),  Venus  (L17D).   Efficient  im- 
plementation of  "P&V"  operations j,  when  these  assumptions 
are  not  true,  might  be  difficult.   Other  systems  permit 
interprocess  interactions  through  a  form  of  logical  com- 
munications other  than  the  use  of  shared  variables  (GE600 
(BD69),  TENEX  (BB71),  ARFA).   One  example  of  how  the  solu- 
tion of  "critical  section"  problems  using  "P&V"  operations 
could  be  difficult  to  implement  (on  a  multiprocessor  sys- 
tem), would  be  when  the  processors  are  using  a  "cache" 
like  buffer  memory.   There  is  normally  no  update  of  the 
information  buffered  by  one  processor  if  another  processor 
changes  a  buffered  variable.   Special  features  would  have 
to  be  introduced  just  to  handle  the  "P&V"  operations.   The 
ARPANET  was  forced  to  U3e  a  message  system  instead  of 
"P&V"  type  operations  for  interprocess  communications 
since  processes  could  reside  in  different  HOSTs  which  did 
not  share  memories.   Wirth  (Wi69)  complains  that  "P&V" 
may  be  too  primitive  anyway,  since  the  synchronization  of 
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loosely  connected  processes  naturally  consists  of  the  in- 
terchange of  messages,  as  is  done  In  ordinary  life. 

Mo3t  systems  do  not  guarantee  either  the  order  of 
execution  or  the  length  of  time  a  physical  processor  will 
be  applied  to  eaeh  process.   Individual  processes  effec- 
tively proceed  asynchronously,  except  through  their  own 
explicit  logical  synchronization.   For  example,  a  common 
way  of  handling  interprocess  communication  is  by  synchron- 
izing the  two  processes  through  such  primitives  as  block/ 
wakeup  or  block/cause  (BD69,  SO69).   Requiring  a  process 
to  go  to  sleep,  when  waiting  for  a  message,  implies  a  sin- 
gle thread  of  control  in  a  process  and  no  logical  inter- 
rupt facilities.   Wirth  (Wi69)  feels  this  is  good  because 
"The  interrupt  effectively  consists  of  the  insertion  of 
one  or  several  instructions  at  points  of  the  program  which 
can  neither  be  foreseen  nor  reconstructed."  On  the  other 
hand,  it  prevents  the  process  from  doing  other  work  while 
waiting  for  messages.   OSL/2  (A17D  has  no  concept  of  an 
interrupt  at  the  logical  level,  and  as  the  author  points 
out,  must  be  completely  "command  driven."   Rose  (Ro7D  is 
the  only  author  who  specifically  discusses  "multi-threaded" 
processes,  although  multiple  threads  are  implicit  in  the 
few  systems  which  do  allow  transfer  to  a  specific  address 
for  the  delivery  of  a  message. 

System-programmers  recognized  early  the  usefulness 
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of  faults  (error  conditions  which  occur  during  the  execu- 
tion of  an  operator  in  a  processor),  and  interrupts  (sig- 
nals from  sources  other  than  the  processor  itself)  but 
user  application  languages  have  been  slow  to  include  such 
concepts.   PL/I  (IB68)  introduced  the  "ON  condition,"  but 
most  other  languages  have  no  such  feature.   Needham  (Ne7D 
feels  that  all  faults  should  be  handled  within  the  process 
using  a  crapping  mechanism.   As  a  general  mechanism,  he 
says  a  process  should  have  a  "catastrophic  address'*  to 
which  control  is  transferred  when  all  else  fails.   The 
major  problem  with  most  present  implementations  of  faults 
is  that  they  are  not  handled  by  the  user  in  the  environ- 
ment in  which  they  occurred,  but  are  treated  as  interrupts 
to  independent  environments.   This  distinction  only  becomes 
essential  in  multiprocess  systems.   The  system  designer 
cannot  expect  to  know  everything  each  user  wants  to  do, 
and  therefore  can  implement  only  arbitrary  design  decisions 
in  such  system  provided  fault  handling  routines. 

Interactions  and  Resources:   Early  computer  systems 
were  not  concerned  with  interprocess  interactions  since 
they  supported  only  one  process  (user)  at  a  time.   As  sys- 
tems became  more  complex,  the  number  of  concurrent  users 
increased,  and  the  amount  of  resident  information  accessi- 
ble to  the  executing  processes  increased.   Uncooperative 
process  behavior  by  design  or  default  became  a  dangerous 
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potentiality,  and  the  control  of  interprocess  interactions 
became  a  necessity.   At  first  the  trend  was  to  isolate  the 
process  completely,  both  logically  and  physically,  but  it 
soon  became  apparent  that  suitable  facilities  had  to  be 
provided  to  permit  processes  to  interact. 

Since  interprocess  interactions  (mutual  or  recipro- 
cal action  or  influence  of  one  process  on  another)  will  al- 
ways exist,  some  form  of  protection  must  be  provided.   A 
good  overview  of  process  protection  can  be  found  in  Co71 
and  De71.   Most  computer  systems,  designed  for  multipro- 
gramming provide  some  control  over  process  interactions, 
such  as  privileged  instructions  or  memory  protection.   For 
example,  the  IBM  360  memory  hardware  protect  and  the  Mul- 
tics  (Or72)  segmentation  binding  within  a  ring,  were  de- 
signed to  limit  a  process's  access  to  its  logical  address 
space  regardless  of  where  it  resided  physically.   Use  of 
a  hierarchical  directory,  with  the  system  checking  access 
rights,  is  the  usual  way  of  protecting  user  files.   One 
problem  in  Venus  (Li7D  is  the  lack  of  segment  protection 
which  requires  but  cannot  ensure  that  all  processes  be  co- 
operative.  Most  of  the  other  systems  make  use  of  disjoint 
logical  process  address  space  (GE600  (BD69),  ESOPE  (BB19)). 
TENEX  (BB71)  and  Multics  (Or72)  integrate  the  file  system 
into  the  virtual  process  address  space,  binding  segments 
to  a  logical  name  only  at  execution  time.   They  hope  to 
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make  sharing  of  data  and  procedures  simpler  since  two  log- 
ical names  can  be  used  by  different  processes,  and  can  be 
mapped  onto  one  physical  name  representing  the  shared  in- 
formation.  One  of  the  major  difficulties  of  permitting 
interprocess  interactions  only  through  shared  segments  is 
that  the  occurrence  of  race  conditions  is  encouraged,  which 
must  be  solved  by  expensive  coope ration,  and  requires  phy- 
sical systems  to  always  provide  a  way  of  sharing  memories 
even  in  a  network.   Interprocess  interactions  using  com- 
munication do  not  have  this  difficulty. 

Achieving  process  protection  by  using  separate  logi- 
cal address  spaces,  created  a  need  for  sharing  logical  en- 
tities.  The  concept  of  a  logical  resource  which  can  be 
passed  to  a  process  was  developed.   Which  entities  are  to 
be  considered  resources,  and  which  processes  are  to  be  per- 
mitted to  have  them,  is  highly  dependent  on  the  level  of 
abstraction  with  which  the  system  is  being  managed.   Until 
recently  resources  were  defined  primarily  in  terms  of  their 
mapping  onto  an  implementation.   The  introduction  of  multi- 
programming, and  the  concepts  of  virtual  machines  and 
virtual  address  spaces,  have  begun  to  separate  what  the 
process  manipulates  from  the  resources  the  implementer 
manipulates.   Pnysical  resources  such  as  space  are  manipu- 
lated by  the  implementor,  and  logical  resources  such  as 
files  are  manipulated  by  the  logical  processes. 
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Some  systems  ars  beginning  to  permit  processes  to 
manipulate  resources.   In  "Venus"  (Li71)  cooperative  re- 
source management  is  used.   In  "Multics"  (Or72),  programs 
and  information  can  be  shared  freely  at  the  will  of  the 
user*   In  "ESOPE"  (BB69)  a  set  of  resources  is  allocated 
to  each  user,  and  it  is  up  to  the  set  of  user  processes 
to  share  them.   Gaines  (Ga71)  limits  a  child  to  a  subset 
of  its  parents*  resources,  as  does  the  RC  4000  (Ha?la) 
system. 

With  the  advent  of  suballocation  of  resources, 
theoretical  work  on  the  protection  of  logical  objects  be- 
comes much  more  important.   Vanderbilt  (Va69)  controls 
access  to  shared  items  by  executing  certain  objects  with- 
in a  data  structure  language  he  has  developed.   Lampson 
(La69,  71)  is  interested  both  in  the  theories  of  protec- 
tion and  in  implementation  problems  such  as  "how  can  in- 
formation which  specifies  protection  and  authorizes  access, 
itself  be  protected  and  manipulated?"  His  theory  suggests 
that  objects  be  named  by  capabilities,  access  be  granted 
to  these  objects  by  keys.   A  process  then  can  be  con- 
sidered to  execute  in  a  domain  (group  of  capabilities), 
and  entry  between  domains  can  be  protected  by  "gates"  thus 
giving  a  process  different  powers  in  different  domains. 
Graham  (Gr71a)  extends  this  work,  and  discusses  the  pro- 
blem in  relation  to  "Sue."   Conway  (CM72)  suggests  another 
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implementation  model  where  the  matrix  elements  "are  deci- 
sion rules  t''  He  makes  a  distinction  between  data  depend- 
ent and  data  independent  rules  which  can  be  exploited  by 
checking  the  data  independent  security  once  at  translation 
time  and  then  checking  only  the  data  dependent  security  at 
execution  time. 

The  protection  of  objects  Is  imperative,  and  any 
general  logical  system  must  provide  some  technique  for 
doing  this.   A  decision  must  be  made  as  to  which  objects 
are  to  be  protected,  the  means  of  protecting  each,  and 
the  rights  of  the  owners  of  such  protected  objects.   A 
design  cannot  be  considered  as  properly  supporting  unco- 
operative processes  unless  protection  is  provided  for  all 
interactions, 

Cooperative  Management  of  Uncooperative  Processes : 
Most  systems  today  lack  a  general  mechanism,  which  the 
process  can  invoke,  for  handling  uncooperative  processes, 
particularly  when  the  process  to  be  controlled  may  exist 
in  some  other  system  in  a  network.   To  be  able  to  do  this, 
mechanisms  must  be  provided  to  allow  for  accountable  re- 
source allocation  and  for  control  (possibly  remote)  of 
interprocess  interactions.   Recently  there  have  been 
several  logical  system  designs  which  have  partial  solu- 
tions to  some  of  these  problems,  but  they  are  too  special- 
ized to  satisfy  all  of  the  requirements  (processes  which 
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must  share  address  space  to  interact,  cannot  be  completely 
Isolated) . 

The  definition  of  uncooperative  behavior  between 
interacting  processes  is  only  possible  from  the  point  of 
view  of  the  authority  over  such  processes.   Several  de- 
signers have  included  process  hierarchies  in  their  systems 
which  permits  a  process  to  control  its  own  subprocesses. 

Since  the  difference  between  operating  sys- 
tems and  production  programs  is  one  of  juris- 
diction only,  this  problem  is  solved  by  ar- 
ranging the  internal  processes  in  a  hierarchy 
In  which  parent  processes  have  complete  con- 
trol over  child  processes.   (Ha70) 

A  child  can  only  be  created,  started,  stopped,  and  removed 
by  a  parent  who  supplies  the  resources  and  gets  them  back 
when  the  child  is  removed. 

Gaines  (Ga71)  is  interested  in  "what  happens  if  a 
process  derails,"  and  TENEX  (BB71)  has  an  "inverted  tree 
defined  by  the  capability  for  direct  control  and  killing." 
"Although  not  completely  general,  a  tree  structure  process 
hierarchy  implicitly  provides  the  protection  and  reference 
facilities  that  are  wanted  in  most  applications."  One  of 
the  design  goals  of  TENEX  was  that  "the  system  should  en- 
courage and  facilitate  cooperation  among  users  as  well  as 
provide  protection  against  undesirable  Interactions." 
There  are  three  areas  which  might  be  considered  deficien- 
cies if  this  system  was  to  be  considered  as  a  network 
structure.   First,  processes  are  permitted  to  communicate 
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via  shared  memory,  which  is  difficult  if  the  hierarchy  is 
distributed  over  nodes  of  the  network.   Second.,  each  "Job" 
is  a  separate  hierarchy,  thus  limiting  some  of  the  general 
interprocess  cooperation  which  might  be  desirable.   Third, 
the  system  does  not  provide  for  logical  resources  to  be 
allocated  down  a  hierarchy  with  guaranteed  protection. 

Portability;   If  useful  portability  is  to  be  possi- 
ble, each  system  must  maintain  a  strict  separation  of  logi- 
cal and  physical  resources,  and  the  logical  system  that  a 
user  sees  should  remain  invariant  over  moves  to  different 
physical  systems.   Landin  (La66)  says  "The  physical/logical 
terminology  is  often  used  to  distinguish  features  that  are 
a  fortuitous  consequence  of  physical  conditions  from  fea- 
tures that  are  in  some  sense  more  essential,"  Given  any 
specific  logical  structure  to  implement,  the  implementer 
usually  has  many  ways  to  do  it.   The  fact  that  the  physi- 
cal system  is  effectively  finite  usually  requires  certain 
constraints  in  the  logical  processes.   For  example,  "THE" 
(Di68)  requires  all  processes  sharing  system  resources  to 
state,  before  the  request  is  made,  what  their  maximum 
needs  for  each  type  will  be. 

Although,  within  the  concept  of  a  virtual  processor, 
users  cannot  directly  control  many  of  the  physical  resources, 
virtual  processors  as  currently  used  do  not  solve  the  prob- 
lems of  portability  because  the  virtual  processor  usually 
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has  an  extremely  close  relationship  to  the  physical  pro- 
cessor on  which  it  is  implemented.   Recently  several  sys- 
tems have  been  implemented  using  a  layered  hierarchy  of 
systems  or  "onion  skin"  structure,   Portability  is  then 
achieved  by  designing  a  logical  structure  at  the  user's 
interface  and  then  implementing  this  structure  as  a  lay- 
ered hierarchy  of  more  abstract  virtual  machines  with  the 
outermost  layer  being  the  logical  system  the  user  sees. 
Project  LOGOS  uses  this  structure  (Br72,  Gl"2a,  bt  HR72, 
RB72).   "The  concept  of  a  layered  hierarchy  of  machines 
is  consistent  with  some  current  trends  in  system  archi- 
tecture and  applies  to  both  hardware  and  software  of  a 
system.   Thus  the  hardware/software  split  can  be  postponed 
in  the  design  process,  allowing  greater  flexibility  of 
implementation."  Several  systems  have  used  this  technique 
in  their  implementations  ("THE"  and  "Venus").   The  design 
of  a  logical  network  which  is  abstracted  from  any  particu- 
lar machine  permits  different  network  facilities  to  imple- 
ment the  design  using  any  desired  number  of  hierarchies 
of  systems.   Using  this  technique,  the  implementer  may 
find  that  it  is  only  the  lowest  levels  of  the  hierarchy 
which  need  redefining.   Regardless  of  what  the  facility 
implementer  must  do  to  provide  the  system,  the  user  will 
see  the  same  basic  logical  structure  when  the  system  is 
finally  implemented. 
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Problem  Statement 

Any  general  but  useful  design  for  networks  of  digi- 
tal computers  must  solve  the  problems  of  network  managea- 
bility, generality,  and  portability.   The  network  designer 
must  determine  which  decisions  should  be  built  into  the 
design,  and  which  should  be  delegated  to  the  users  or  the 
implementers  to  make  at  a  later  time.   The  more  decisions 
built  into  a  network  design,  the  less  adaptable  the  net- 
work will  become  and  the  less  freedom  the  user  will  have 
to  create  optimal  process  relationships.   A  solution, 
which  does  not  result  in  arbitrary  or  unnecessary  con- 
straints on  the  network  users  or  implementers,  is  to  de- 
sign into  the  system  itself,  only  the  choices  necessary 
to  permit  the  network  designer  to  delegate  all  other  de- 
cisions to  either  the  users  or  the  implementers. 

The  system  designed  in  this  thesis,  provides  suffi- 
cient factorization  of  responsibilities  and  delegation  of 
authority  to  control  the  behavior  of  the  processes  running 
in  the  network,  to  permit  the  development  of  a  network 
which  satisfies  the  following  postulated  constraints. 

1.  The  designed  network  must  consist  of  a  set  of 
interacting  bounded  programmable  digital  computer  systems 
with  well-defined  processes,  and  be  open  to  communication 
with  foreign  systems  having  undefined  processes. 

2.  Responsibility  for  meeting  the  postulated 
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design  constraints  and  the  design  decisions  must  be  fac- 
tored between  the  network,  implementation,  and  process  de- 
signers. 

3*   Each  designer  must  have  sufficient  authority  to 
control  the  effects,  on  the  processes  running  in  che 
network,  of  the  interactions  for  which  that  designer  has 
been  delegated  responsibility. 

4.  Although  processes  must  be  permitted  to  dele- 
gatr  to  other  processes  their  authority  to  control  process 
Interactions s  the  delegating  process  always  retains  re- 
sponsibility for  that  interaction  and  the  authority  to 
control  the  process  to  which  it  was  delegated. 

5.  The  network  definition  must  provide  for  modifi- 
cation of  its  definition.  The  design  must  provide  suffi- 
cient constraints  to  be  able  to  delegate  safely  to  process 
designers  all  modification  decisions  and  authority  to  con- 
trol the  effects  of  such  decisions  on  the  processes  in  the 
network. 

The  postulated  constraints  must  always  be  satisfied 
when  design  decisions  are  made  in  this  thesis.   Those  de- 
sign decisions  influenced  by  the  postulated  constraints 
must  be  shown  to  provide  the  greatest  generality  consist- 
ent with  the  postulated  and  derived  constraints.   Those 
decisions  which  are  not  directly  influenced  by  the  con- 
straints need  only  be  made  subject  to  good,  but  informal, 
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design  concepts. 

Chapter  2  of  this  thesis  contains  the  development 
of  a  set  of  constraints  within  which  the  network  deci- 
cions  will  be  made.   The  postulated  constraints  are  moti- 
vated first,  and  then  additional  constraints,  which  follow 
directly  from  them,  are  developed.   The  third  chapter  de- 
velops and  informally  defines  the  network  design  consist- 
ent with  the  constraints  developed  in  Chapter  2.   Chapter 
H   uses  the  network  structures  to  describe  several  other 
representative  systems,  discusses  both  the  implications 
of  this  work,  and  of  other  work  being  done  in  parallel 
with  this  thesis,  and  describes  some  of  the  areas  which 
deserve  future  i^esearch.   A  formal  definition  of  the  de- 
signed network  is  given  in  Appendix  C. 
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Once  a  satisfactory  set  of  criteria 
and  postulates  has  been  formulated,  then 
one  may  deduce,  rather  than  design,  the 
structure  of  a  computer  (Van  Horn,  Va66, 
p.  227). 


CHAPTER  2 
NONCOOPERATION  -  THE  SOLUTION 

Introduction 

The  previous  chapter  described  some  of  the  problem 
areas  associated  with  current  networks  and  systems,  along 
with  some  of  the  present  approaches  to  solving  those  prob- 
lems.  This  chapter  will  develop  a  set  of  design  con- 
straints sufficient  to  allow  the  solution  of  network  man- 
agement problems  arising  from  the  inclusion  of  general 
control  structures,  potentially  uncooperative  processes, 
and  portability  of  user  processes  and  the  design  itself. 
The  problem  of  process  noncooperation  will  be  looked  at 
briefly,  and  the  postulated  constraints  will  be  motivated. 
Additional  constraints,  which  define  the  delegation  of 
authority  to  control  certain  process  interactions,  will 
be  developed  from  the  postulated  constraints. 

A  solution  to  the  problem  of  process  noncooperation 
is  necessary  if  a  network  designer  is  to  be  able  to  give 
process  designers  responsibility  and  authority  to  control 
the  processes  in  the  network.   A  direct  approach  to  the 
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problem  of  process  noncooperation  Is  difficult  because 
there  Is  no  objective  point  of  view  from  which  to  decide 
that  noncooperation  exists.  What  is  considered  coopera- 
tive by  one  process  designers  might  be  considered  uncoop- 
erative by  another.   A  final  judgment,  by  definition,  can 
only  be  made  by  the  proper  authority,  which  might  exist 
as  a  single  designer  or  cooperatively  as  joint  designers. 
Three  levels  of  authority  exist  in  most  computer  systems 
today:   user,  operating  system,  and  implementation.   One 
of  the  major  problems,  usually  encountered  in  cur-rent  sys- 
tems, is  the  lack  of  a  clear  factorization,  between  these 
three  groups,  of   the  responsibility  for  the  control  of 
process  behavior  and  authority  to  do  so,   Operating  sys- 
tem and  implementation  designers  (commonly  Indistinguish- 
able) often  know  very  little  about  what  the  user  intended 
a  process  to  do,  and  therefore  can  only  make  general  as- 
sumptions about  it  when  trying  to  manage  its  behavior. 

It  is  unlikely  that  tho  network  designer  will  ever 
know  all  viewpoints  from  which  to  judge  process  noncooper- 
ation since  this  would  require  complete  knowledge  of  what 
all  users  of  the  network  were  logically  trying  to  accom- 
plish.  Analysis,  by  the  network  designer,  of  process  non- 
cooperation  would  only  lead  to  ncnformal  systems  and  a 
philosophical  discussion.   The  network  designer  should  not 
make  arbitrary  decisions  for  the  user  by  decreeing  which 
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process  actions  are  to  be  considered  cooperative  3.nd  which 
are  not,  but  should  provide  services  to  the  appropriate 
agent  responsible  for  that  process  to  make  the  decision. 

The  key  to  the  problem  of  process  noncooperation 
is  that  there  must  be  at  least  two  interacting  parties  be- 
fore cooperation  or  lack  of  it  can  have  any  meaning.   It 
takes  at  least  two  marching  soldiers  before  they  can  be 
out  of  step.   The  one  declared  out  of  step  is  clearly  not 
the  ranking  authority  unless  it  was  a  cooperative  self 
declaration  because  of  incompetence.   If  all  interactions 
in  the  network  can  be  recognized,  and  a  safe  means  pro- 
vided by  which  they  can  be  controlled,  the  network  de- 
signer can  delegate  responsibility  and  authority  for  the 
management  of  such  interactions  to  other  agents.   A  logi- 
cal state  structure,  as  distinct  from  a  physical  imple- 
mentation of  it,  must  be  imposed  on  the  processes  along 
with  the  definition  of  appropriate  transformations  on 
these  states,  so  that  the  effects  of  all  process  opera- 
tions are  known.   If  the  scope  of  the  effects  of  a  pro- 
cesses' potential  noncooperation  is  well-defined,  respon- 
sibility for  process  noncooperation  can  be  delegated  to 
the  processes  concerned.   (Well-defined:   Something  is 
considered  well  defined  if  it  has  been  formally  defined 
and  the  definition  holds  over  all  systems  in  the  network. ) 

If  process  designers  are  to  be  delegated  the 
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responsibility  for  controlling  process  noncooperation,  me- 
chanisms must  be  provided  within  the  network  design  for 
the  control  of  process  interactions  through  which  the 
effects  of  noneooperation  can  be  transmitted.   As  systems 
became  more  complex,  more  than  one  dimension  of  responsi- 
bility and  authority  for  the  control  of  processes  devel- 
oped.  Users  of  early  computers  had  complete  control  of 
the  machine  and  hence  were  completely  responsible  for  their 
pr-uoesses.  but  as  systems  became  more  complex,  the  user  was 
no  longer  uniquely  responsible  for  what  was  happening. 

For  each  interaction  between  processes,  a  proper 
partitioning  would  designate  a  responsible  agent  v/ho  could 
then  be  given  authority  to  control  that  interaction.   In- 
teractions between  processes  can  occur  because  of  the 
existence  of  a  process,  the  logical  expectations  of  a  pro- 
cess, and  interprocess  communication. 

The  existence  of  a  process  may  cause  interactions 
with  other  processes  because  the  implementation  must  use 
some  of  its  limited  physical  resources  to  represent  it. 
The  birth  of  a  new  process  or  death  of  an  old  one  can  pos- 
sibly cause  interactions  because  of  limited  rights  to  cre- 
ate or  kill  a  process,  the  use  of  objects  borrowed  from 
other  processes,  or  the  use  of  some  of  the  physical  pro- 
cesser  time  during  the  operation.   Interactions  might  also 
occur  if  a  process  is  able  to  manipulate  the  physical  sys- 
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tern  to  get  faster  service  or  more  resources,  generate  in- 
valid state  structures 9  or  to  change  a  microprogram  which 
another  process  might  need  to  use. 

Interactions  due  to  the  logical  expectations  of  one 
process  with  respect  to  the  behavior  of  another  process 
make  up  a  second  category  of  potential  sources  of  non-coop- 
eration.  Scheduling  expectations  might  include  not  doing 
what  another  process  wants,  doing  things  in  the  wrong  or- 
der, or  not  giving  control  back.   A  processes'  management 
of  resources  might  cause  problems  by  not  returning  re- 
sources, allocating  them  improperly,  not  accounting  for 
what  has  been  done  with  them,  and  changing  or  destroying 
them. 

Finally,  interprocess  communication  can  be  a  po- 
tential source  of  noncooperation.   A  process  might  not  be 
able  to  find  out  the  status  of  another  process  if  the 
other  process  is  disregarding  inputs  or  not  sending  out- 
puts. Messages  might  be  garbled  or  lost  if  input  process- 
ing is  too  slow.   Shared  address  spaces  might  permit  im- 
proper state  changes,  modifying  or  destroying  commonly 
addressed  objects,  as  well  as  both  logical  and  physical 
race  problems  with  respect  to  accessing  common  objects. 

Although  the  above  examples  are  not  complete,  they 
do  indicate  some  of  the  interactions  which  a  network  de- 
sign must  consider.   The  network  designers  and  implementers 
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can  be  responsible  for  controlling  some  of  then,  however 
the  responsibility  for  the  majority  of  them  must  be  dele- 
gated to  the  process  designers  since  in  many  situations 
only  the  user  has  the  knowledge  required  to  recognize  un- 
cooperative processes. 

Postulated  Design  Constraints 

There  are  five  postulated  design  constraints  which 
are  sufficient  to  permit  a  network  to  be  designed  which 
can  be  ujed  to  provide  a  solution  to  network  management 
problems.   Each  constraint  will  have  a  discussion  follow- 
ing it  which  is  intended  to  explain  the  terms  used  in  it 
and  motivate  why  the  constraint  was  included. 

Constraint  CI  -  The  designed  network  must 
consist  of  a  set  of  interacting  bounded 
programmable  digital  computer  systems  with 
well-defined  processes,  and  be  open  to  com- 
munication with  foreign  systems  having  un- 
defined processes. 

Bounded  -  A  logical  system  will  be  considered  to 
be  bounded  if  it  defines  the  logical  effects  of  implemen- 
tation failures  which  may  occur  because  the  implementer 
has  only  a  limited  amount  of  physical  resources  of  limited 
reliability  with  which  to  work.   The  logical  system  does 
not  define  when  the  implementation  failures  will  occur; 
this  can  only  be  determined  by  an  evaluation  of  each  im- 
plementation and  may  in  fact  change  with  time. 
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We 11- defined  processes  -  A  process  will  be  con- 
sidered well-defined  if  it  has  been  formally  defined  and 
if  the  definition  holds  over  ail  systems  in  the  network. 

Foreign  system  -  A  system  that  interacts  with  the 
systems  in  the  network  and  which  is  constrained  by  the 
network  designers  only  in  the  nature  of  these  interac- 
tions. 

Uride fined  proc es s  -  Any  process  which  is  not  for- 
mally defined  in  the  network.   We  can  therefore  make  no 
assumptions  about  its  behavior. 

The  first  constraint  is  intended  to  limit  the 
scope  of  the  network  structures  which  will  be  developed 
in  the  next  chapter.   It  should  always  be  kept  in  mind 
that  this  is  a  general  logical  network  design  and  as  such 
makes  no  assumptions  about  the  physical  systems  upon  which 
it  may  be  implemented.   With  the  advent  of  networks,  any 
general  system  design  must  consider  the  possibility  that 
the  processes  residing  in  different  systems  may  wish  to 
interact. 

A  design  which  is  appropriate  for  a  network  of 
interconnected  computer  systems  can  be  constrained  to  run 
on  a  single  system,  but  it  may  not  be  possible  to  extend 
a  single  system  design  to  run  on  a  network  and  still  pro- 
vide satisfactory  generality.   The  situation  where  the 
network  provides  little  more  than  interconnection  services 
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between  systems,  and  each  logical  operating  system  is  de- 
veloped separately,  is  also  not  satis factory .   The  user, 
whose  processes  span  several  systems  in  the  network,  must 
design  each  process  to  operate  properly  on  its  HOST  sys- 
tem which  may  limit  the  computation's  flexibility  (TH72). 
This  problem  can  be  avoided  if  the  design  includes  a  net- 
work as  a  basic  postulate  and  then  includes  process  state 
structures  and  operations  on  these  states  which  are  as 
general  as  possible.   By  providing  a  common  logical  sys- 
tem design  at  each  system  in  the  network,  the  design  per- 
mits the  user  to  easily  understand  the  network  and  the 
processes  it  will  support.   It  is  a  network  design  that 
is  of  interest  in  this  thesis. 

"Interacting" — When  looking  at  an  arbitrary  set  of 
systems,  it  is  convenient  to  be  able  to  say  whether  or  not 
each  member  of  the  set  is  also  a  member  of  the  network. 
Only  systems  which  interact  with  other  systems  of  the  net- 
work can  be  candidates  for  membership  in  the  network.   If 
a  system  does  not  interact  with  a  system  in  the  network 
then  it  is  not  of  interest  in  this  thesis.   Foreign  sys- 
tems are  not  considered  to  be  members  of  the  network. 

"Bounded"  systems  must  be  included  in  the  design 
in  recognition  of  the  fact  that  the  physical  implementa- 
tion will,  for  all  practical  purposes,  have  access  to  only 
limited  physical  resources.   The  network  design  must 
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recognize  this  fact,  arid  properly  designate  responsibility 
for  the  process  interactions  which  can  occur  due  to  it. 

"Programmable11— If  the  design  were  not  restricted 
to  programmable  computer  systems,  several  networks  could 
be  designed  which  might  not  be  considered  general.   Sys- 
tems which  exhibit  totally  built  in  reflexes  (not  pro- 
grammable by  the  user) ,  such  as  airline  reservation  sys- 
tems, although  interesting,  have  a  design  which  could  not 
be  easily  extended  to  a  network  where  the  users  are  de- 
fining many  of  the  processes.   On  the  other  hand,  a  design 
providing  for  user  programmable  systems,  could  be  user,  to 
implement  the  reflex  system. 

"Digital  computer"  systems  have  several  properties 
which  make  them  nice  to  study.   The  design  problems  they 
present  should  be  solved  before  looking  at  more  complex 
networks.   Although  the  formal  definition  of  "digital  sys- 
tem" being  used  in  this  thesis  can  be  found  in  PH71  and 
Jc-73,  the  essential  concepts  will  be  introduced  here  in- 
formally.  It  is  important  to  recognize  that  there  is  a 
distinction  between  a  single  digital  system  and  a  network 
of  interacting  digital  systems.   A  digital  system  has 
three  primary  parts:   a  set  of  components  which  hold  in- 
formation; a  set  of  devices  which  are  capable  of  perform- 
ing transformations  on  the  information  stored  in  those 
components;  and  a  set  of  communication  "channels." 
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The  "system  processor"  is  that  part  cf  the  digital 
system  which  performs  the  transformations  and  is  itself 
invariant  v/ith  time.   It  may  contain  one  or  more  operators 
which  carry  cut  transformations  on  process  states.   Each 
operator  is  applied  as  follows.   All  operators  which  are 
to  be  executed  during  the  present  system  cycle  are  applied 
in  parallel  at  the  beginning  of  the  system  cycle  and  then 
proceed  asynchronously.   The  next  system  cycle  does  not 
commence  until  all  operators  have  completed  and  the  system 
has  again  reached  a  defined  state, 

A  "system  process"  is  an  initial  instantaneous  des- 
cription of  the  whole  state  cf  the  system,  followed  by  all 
of  those  states  reached  by  repetitive  application  of  the 
system  processor.   The  system  state  may  contain  a  set  of 
one  or  more  process  states  which  represent  different  parts 
of  the  system  state  (for  example,  user  process  states). 
A  "process"  within  a  digital  system  can  thus  be  defined 
by  its  initial  process  state  and  the  sequence  of  process 
states  reached  as  the  system  processor  operators  are  ap- 
plied to  it. 

Each  digital  system  In  a  network  has  a  system  state 
and  system  processor  which  perform  the  transformations  on 
that  state.   Each  system  processor  proceeds  at  its  own 
pace  through  its  interpretation  sequence,  without  any  con- 
sideration of  the  speed  at  which  the  other  members  of  the 
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set  are  proceeding.   Because  there  is  no  synchronization 
between  different  systems,  there  must  be  a  clear  under- 
standing of  intersystem  communication.   Each  system  pro- 
ceeds as  follows.   If  messages  are  generated  during  the 
application  of  the  system  processor,  they  are  collected 
in  a  set,  and  when  the  system  processor  completes  its  cy- 
cle they  are  transmitted  to  the  other  systems,   After 
transmitting  the  messages,  the  system  updates  its  own 
state  with  the  messages  that  have  arrived  since  the  pre- 
vious update  and  the  next  cycle  begins.   Incoming  mes- 
sages are  buffered  between  updates  since  (in  a  digital 
system)  they  must  not  influence  the  interpretation  during 
the  application  of  the  system  processor.   This  is  closely 
analogous  to  the  ordinary  concepts  of  intersystem  inter- 
rupts. 

"Well-defined"  processes  are  necessary  before  any 
assumptions  can  be  made  concerning  their  behavior.   For 
example,  the  creation  of  a  new  user  process  state  must  be 
controlled  so  it  can  be  recognized  as  such  by  the  system 
processor.   Each  process  state  may  have  several  parts 
which  must  remain  invariant,  irrespective  of  what  is  hap- 
pening in  that  system  or  in  any  other  system  in  the  net- 
work. 

A  network  will  be  considered  "open"  if  the  pro- 
cesses, when  executing  on  one  of  the  network  systems,  have 


k2 
the  ability  to  communicate  messages  to  and  i'-eceive  mes- 
sages from  foreign  systems  (using  normal  interprocess  com- 
munication only).   Although  it  would  nave  been  possible  to 
have  considered  a  closed  network,  where  communication  could 
be  exchanged  only  between  processes  in  the  network,  there 
would  have  been  many  interesting  process  interactions  which 
would  have  been  ruled  out.   Since  it  would  be  difficult  for 
the  network  designer  to  be  able  to  know  how  to  interpret 
the  logical  structure  of  all  future  message  interactions 
with  foreign  systems,  this  is  left  up  to  the  process  to  do. 

The  same  mechanism  will  be  used  for  communication 
with  foreign  systems  as  is  used  for  interprocess  messages 
between  processes  in  the  network.   As  a  result,  no  special 
structures  will  have  to  be  provided  by  the  network  design- 
er, to  service  these  external  interactions.   Even  though 
foreign  systems  will  not  be  formally  defined  in  the  network 
and  therefore  nothing  can  be  said  about  the  behavior  of 
their  processes,  as  long  as  the  communication  operators 
are  formally  defined,  and  appropriate  constraints  placed 
on  their  effects  on  the  network  systems,  the  network  pro- 
cesses can  still  remain  formally  defined.   Since  the  net- 
work designers  have  no  authority  over  the  design  of  for- 
eign systems,  they  must  localize  the  potential  effects  of 
process  interactions  with  such  systems.   By  restricting 
such  interactions  to  messages  to  and  from  a  process  in  the 


network,  potential  Interactions  are  limited  to  that  pro- 
cess.  The  network  design  must  only  ensure  that  such  mes- 
sage interactions  are  possible,  and  that  the  processes 
have  control  over  the  receipt  and  interpretation  of  such 
messages. 

Constraint  C2  -  Responsibility  for  meeting 
the  postulated  design  constraints  and  de- 
sign decisions  must  be  factored  between 
the  network,  implementation,  and  process 
designers. 

In  this  thesis  it  is  only  those  interactions,  for 
which  one  of  these  three  designers  may  be  held  responsible, 
that  will  be  discussed.   Although  other  designers  (manage- 
ments) may  exist  in  a  network  and  may  be  important,  they 
are  not  of  interest  here.   In  order  for  the  network  to  be 
manageable,  there  must  be  no  conflicts  of  authority  or 
improper  assignment  of  responsibility.   For  these  three 
designers  there  must  be  a  partitioning  of  responsibility 
which  is  disjoint  in  time.   The  network  designer  influences 
process  Interactions  by  the  features  included  in  the  de- 
sign, the  implementation  designer  influences  process  be- 
havior by  the  physical  resources  chosen  with  which  the  de- 
sign is  implemented,  and  the  process  designer  is  responsi- 
ble for  controlling  process  behavior  by  the  features  chosen 
with  which  to  define  it. 

The  separation  of  logical  and  physical  resources 


found  In  some  sy;  terns  today  is  part  of  such  factorization. 
The  physical  resources  are  managed  by  the  implementation. 
Logical  processes  make  requests  to  use  certain  resources, 
but  the  mapping  from  logical  to  physical  is  not  necessari- 
ly 1  -  1,   Since  not  all  implementations  In  a  network  will 
come  under  one  management,  the  network  design  provides  the 
common  interface  between  the  Implementers  and  the  process 
designers.   If  responsibility  is  clearly  factored,  each 
designer  can  solve  its  own  management  problems  in  a  lo- 
cally optimal  manner,   The  development  of  more  complex 
systems  and  the  distribution  of  a  set  of  processes  over 
a  network  make  it  imperative  that  the  responsibilities  of 
the  network,  implementation,  and  process  designers  be 
clearly  stated.   Identification  of  these  responsibilities 
Will  permit  bhe  network  designer  to  introduce  appropriate 
mechanisms  so  each  responsible  agent  can  fulfill  its  re- 
sponsibilities . 

Of  primary  interest  here  are  the  process  state 
structures  and  system  processor  operators  necessary  for 
the  process  and  network  designers  to  do  their  job.  Al- 
though the  implementation  of  the  network  design  on  par- 
ticular architectures  will  require  much  design  work,  no 
assumptions  will  be  made  here  about  the  way  the  physical 
implementers  will  solve  their  problems.  Until  there  Is 
a  network  design  to  implement,  questions  concerning  im- 
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plementation  are  only  secondary. 

Constraint  C2  requires  that  responsibility  for  meet- 
ing the  postulated  design  constraints  and  design  decisions, 
including  the  interactions  mentioned  earlier,  be  assigned 
to  one  of  the  three  designers,   Within  the  network,  each 
implementation  management  must  be  free  to  manage  the  re- 
sources it  is  using  to  implement  the  network.   Therefore 
it  must  have  responsibility  for  such  resources  so  it  can 
meet  its  own  optimization  criteria.   If  users  are  to  be 
permitted  to  construct  interesting  and  useful  process  re- 
lationships, process  designers  must  be  assigned  responsi- 
bility for  the  definition  of  these  processes.   The  network 
design  must,  of  course,  define  the  Interfaces  between  each 
of  the  other  designs,  and  therefore  must  have  responsibil- 
ity for  providing  a  well-defined  interface  and  for  con- 
trolling Interactions  between  the  other  designs. 

Constraint  C3  -  Each  designer  must  have  suf- 
ficient authority  to  control  the  effects,  on 
the  processes  running  in  the  network,  of  the 
interactions  for  which  that  designer  has  been 
delegated  responsibility. 

If  responsibility  for  controlling  the  effects  of 
process  interactions  is  factored  between  network,  imple- 
mentation, and  process  designers,  then  each  designer  must 
define  and  control  uncooperative  process  interactions. 
Since  noncooperation  is  a  point  of  view,  only  the  re- 
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sponsible  agent  can  determine  when  some  action  is  uncoop- 
erative.  It  was  pointed  out  earlier  that  process  noncoop- 
eration  can  be  controlled  only  by  restricting  the  effects 
of  the  various  interactions  through  which  it  can  occur. 
Each  of  the  three  designers,  therefore,  must  be  given  such 
authority  to  restrict  the  effects  of  the  interactions  for 
which  it  is  responsible.   Only  then  can  each  designer  im- 
plement a  local  control  of  cooperation  or  lack  of  it. 

Although  constraint  C2  requires  that  responsibility 
be  factored  between  the  three  designers,  nothing  would 
have  been  solved  without  the  addition  of  constraint  C3. 
Responsibility  to  control  process  interactions  without 
the  associated  authority  to  carry  out  those  responsibili- 
ties would  be  meaningless.   The  network  design  must  in- 
clude sufficient  logical  process  state  structures  and 
system  processor  operators  for  a  designated  responsible 
agent  to  control  those  interactions  which  the  design  has 
defined  a3  its  responsibilities.   Responsibility  and 
authority  must  both  reside  with  the  same  agent. 


Constraint  Ck   -  Although  processes  must  be 
permitted  to  delegate  to  other  processes 
their  authority  to  control  process  inter- 
actions, the  delegating  process  always  re- 
tains responsibility  for  that  interaction 
and  the  authority  to  control  the  process 
to  which  it  was  delegated. 

This  constraint  must  be  postulated  if  process  de- 
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signers  are  to  have  the  flexibility  to  do  their  job.  The 
intent  is  not  to  design  a  process  independent  system,  but 
just  the  opposite.  The  design  should  permit  the  user  to 
define  multiprocess  computations  which  are  highly  process 
dependent.  Several  recent  system  designs  include  such  a 
service  to  the  users  (TENEX,  RC^OOO). 

The  question  of  whether  or  not  a  given  process  de- 
signer should  make  use  of  multiprocess  computations  does 
not  belong  here,  although  it  is  not  difficult  to  think  of 
examples  where  doing  so  makes  design  of  process  behavior 
much  simpler.   A  simple  example  would  be  a  logical  operat- 
ing system  which  has  three  primary  processes  running  under 
it  (time  sharing,  batch,  and  utility).   The  operating  sys- 
tem designer  might  want  to  have  one  process,  which  retains 
ultimate  authority,  to  arbitrate  conflicts  between  the 
other  three  processes,  but  to  delegate  the  authority  to 
make  local  decisions  to  the  three  children. 

The  delivery  of  maximum  freedom  to  user  processes 
to  manage  other  local  processes,  requires  that  they  be  con- 
sidered as  submanagers  and  given  corresponding  authority 
to  control  process  behavior  necessary  to  fulfill  their 
responsibilities.   Process  submanagers  should  be  able  to 
construct  their  computations  as  multiple  interacting  pro- 
cesses and  be  able  to  delegate  some  of  their  authority  to 
subprocesses  over  which  they  retain  ultimate  responsibility 
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and  authority.   The  user  can  then  create  various  operat- 
ing environments  for  sets  of  subprocesses  in  a  hierarchy 
of  user  defined  operating  systems.   Instead  of  requiring 
one  process  to  make  all  decisions  according  to  a  general 
algorithm,  authority  can  be  passed  to  other  processes  to 
make  the  decisions  in  a  locally  optimal  manner.   Con- 
straint C>1   is  Intended  tc  force  the  network  designer  to 
include  the  ability  for  processes  to  delegate  responsi- 
bility and  authority.   A  clear  designation  will  have  to  be 
made  as  to  which  responsibilities  the  network  designer 
will  delegate  to  the  process  designers. 

Constraint  C5  -  The  network  definition 
must  pr617rdir~for  modification  of  its  def- 
inition.  The  design  must  provide  suffi- 
cient constraints  to  be  able  to  delegate 
safely  to  process  designers  all  modifica- 
tion decisions  and  authority  to  control 
the  effects  of  such  decisions  on  the 
processes. 

Any  network  design,  which  is  to  survive  over  a 
period  of  time,  must  recognize  the  fact  that  changes  will 
be  necessary.   Additional  systems  may  be  added  to  the  net- 
work or  new  process  state  structures  may  develop.   Con- 
straint C5  requires  the  final  network  design  to  define 
what  types  of  network  evolutions  will  be  permitted,  along 
with  the  environments  in  which  they  may  take  place  and 
under  what  constraints.   If  these  evolutionary  processes 
were  not  so  constrained,  an  implementation  designer  could 
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never  know  that  the  implementation  was  valid. 

Process  designer  support  is  the  whole  reason  for 
any  computer  system  design.   It  would  be  inconsistent  to 
give  process  designers  responsibilities  for  some  interac- 
tion and  then  perrrit  the  network  to  be  modified  and  effect 
that  interaction  without  the  "consent"  of  that  designer. 
If  the  network  is  to  support  well-defined  processes  as  re- 
quired by  constraint  CI,  process  designers  must  make  the 
decisions  as  to  whether  or  not  some  modification  will  cause 
some  of  their  processes  to  misbehave.   Implicit  in  this 
constraint  is  the  fact  that,  because  of  the  three  way  fac- 
toring of  responsibility  for  controlling  process  interac- 
tions, there  will  be  some  interactions  which  will  be  the 
responsibility  of  the  network  and  implementation  designers 
and  therefore  should  not  be  available  to  the  process  de- 
signers 6   The  control  that  process  designer  has  over  the 
effects  of  network  definition  modifications  will  be  deter- 
mined by  the  factoring  of  responsibility  required  by  con- 
straint C2. 

Delegation  of  Authority  Constraints 

The  previous  section  introduced  the  design  con- 
straints that  are  being  postulated  in  this  thesis.   The 
remainder  of  this  chapter  will  develop  some  additional 
constraints  which  follow  from  the  postulated  constraints. 
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This  section  looks  at  some  authority  delegation  constraints 
arising  primarily  from  C2  and  C3. 

Delegation  Constraint  Dl  -  Responsibility  for 
each  interaction  and  authority  to  control  it 
must  be  uniquely  assigned  to  the  same  designer. 

This  constraint  follows  directly  from  C2  and  C3. 
Although  it  is  implicit  in  the  previous  constraints,  it 
should  be  clearly  stated  as  a  constraint  so  the  network 
designer  makes  such  a  unique  designation  when  a  choice 
exists.   If  a  designer  is  designated  as  responsible  for 
controlling  an  interaction,  it  would  not  be  consistent  to 
permit  another  agent  to  also  have  control  over  it.   The 
responsible  agent  would  no  longer  be  responsible  and  con- 
straint C2  would  be  violated.   A  designer  with  authority 
to  control  an  interaction  must  be  able  to  act  on  its  own 
initiative,  subject  only  to  its  design  constraints. 

A  constraint  similar  to  Dl  is  necessary  in  any  de- 
sign that  is  to  produce  a  manageable  system.   Each  design- 
er must  be  able  to  solve  its  problems  in  any  locally  op- 
timal manner,  without  fear  that  some  other  designer  is 
also  competitively  controlling  that  same  interaction  with 
resulting  conflict  of  authorities.   If  conflicts  of  author- 
ity existed  in  a  system,  the  system  would  no  longer  be 
guaranteed  to  be  manageable  unless  there  were  an  arbitrator 
present  to  settle  the  conflict.   If  such  an  authority  does 
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exist ,  then  it  is  the  unique  authority  this  constraint 
says  must  exist. 

The  recognition  that  this  constraint  exists,  pro- 
vides the  network  designer  the  freedom  to  delegate  to  the 
other  designers  the  responsibility  for  solving  their  own 
problems.   Once  an  interaction  is  designated  as  being  the 
responsibility  of  one  of  the  three  groups  of  designers, 
mechanisms  can  be  provided  to  permit  those  designers  to 
solve  their  problems.   The  network  design  does  not  have 
to  make  arbitrary  choices  of  algorithms  to  solve  particu- 
lar prob]enc,  but  can  defer  the  choice  of  which  algorithm 
to  use  to  the  appropriate  designer.   Unique  assignment  of 
authority  permits  the  designer  to  delegate  the  maximum 
number  of  responsibilities  to  the  facility  and  process 
designers.   This  results  in  a  simplified  network  design 
which  still  fulfills  the  responsibilities  of  the  network 
designers. 

Delegation  Constraint  D2  -  Network  designers 
are  responsible  for  ensuring  that  the  network 
is  self-protecting,  meets  the  constraints,  and 
is  formally  defined. 

Constraint  D2  follows  directly  from  the  second 

postulated  constraint  requiring  that  responsibility  for 

interactions  be  assigned  to  one  of  three  designers.   The 

network  design  provides  the  interface  between  the  process 

and  implementation  managements.   The  remainder  of  this 
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thesis  will  define  this  interface. 

Self-protecting  -  A  network  is  self-protecting  if 
there  are  sufficient  constraints  on  the  freedoms  of  future 
designers  (implementation  and  process)  so  their  actions 
cannot  affect  the  network  in  any  way  which  would  cause  it 
to  violate  any  of  the  constraints  or  design  decisions. 

If  the  design  were  not  made  self-protecting,  con- 
straint violating  inter-actions  might  occur  between  the 
process  and  implementation  designers.   If  all  implementa- 
tion designers  were  under  one  authority,  or  if  all  pro- 
cesses were  known  to  be  cooperative,  then  the  protection 
responsibility  could  be  delegated  to  them.   Since  we  can- 
not assume  either  of  these  situations  to  be  true,  the  only 
common  designer  in  all  cases  is  the  network  designer.   The 
network  designer  thus  is  the  only  agent  capable  of  ful- 
filling this  need.   A  need  for  network  self-protection 
exists  if  the  processes  are  to  be  well-defined. 

Ensuring  that  the  network  design  meets  the  con- 
straints is  an  obvious  requirement  of  the  network  design- 
er.  The  process  and  implementation  designers  cannot  be 
held  responsible  for  this  requirement  since  neither  one 
of  them  has  enough  global  information  to  know  if  the  net- 
work meets  the  constraints  or  not. 

Formally  defining  the  network  must  be  a  responsi- 
bility of  the  network  designers  since  they  are  responsible 
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for  the  design  in  the  first  place.   A  formal  definition  is 
required  if  the  network  designers  are  to  expect  it  to  be 
unambiguously  understood  by  the  implement ers  and  the  network 
users.   It  must  also  be  formally  defined  If  the  designer 
is  to  know  that  it  satisfies  the  design  constraints. 

Design  Constraint  D3  -  The  implementation 
designers  are  responsible  for  the  design, 
construction,  and  maintenance  of  an  opti- 
mal equivalent  system. 

An  equivalent  system  is  one  In  which  the  processes 
are  isomorphic  to  the  processes  as  formally  defined.   Con- 
straint D2  recognizes  that  the  network  v/ill  be  implemented 
and  that,  according  to  constraint  C2,  some  agent  must  be 
held  responsible  for  the  implementation.   Each  implementa- 
tion designer  is  uniquely  capable  of  determining  what  the 
optimal  implementation  at  that  facility  v/ill  be.   Only 
the  implementation  designer  knows  what  physical  resources 
are  present  or  can  be  obtained  at  that  facility.   Each  im- 
plementer  must  first  design  an  equivalent  system  according 
to  Its  own  management  constraints,  then  construct  such  an 
equivalent  system,  and  finally  maintain  that  equivalent 
system. 

This  constraint  permits  the  local  designers  to  con- 
tinue to  optimize  their  local  implementations  since  they 
have  complete  responsibility  for  the  equivalent  implementa- 
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tion  designer  from  moving  an  implementation  to  another 
physical  machine  or  making  modification  to  the  current  im- 
plementation.  As  long  as  the  implementation  remains  equiv- 
alent, the  local  implementation  designer  is  free  to  make 
any  changes  in  the  implementation  deemed  desirable. 

The  success  that  a  network  achieves  in  exploiting 
this  delegation,  of  responsibility  and  authority  to  the 
implementation  designer,  will  be  highly  dependent  on  the 
particular  design  chosen.   It  is  particularly  important 
that  no  one-to-one  mappings  be  required  between  particular 
features  of  the  logical  network  design  and  particular  phy- 
sical resources  which  might  be  available.   Note  that  this 
says  one-to-one  mappings  required  by  the  design.   One-to- 
one  mappings  which  result  by  accident  or  the  design  of  the 
implementcrs  might  be  beneficial  because  of  potentially  in- 
creased efficiency,  and  is  a  choice  of  the  implementers 
though  and  within  their  authority.   Today's  system  designs 
often  depend  on  such  mappings  and  this  makes  them  costly 
to  move.   If  the  "impressive  improvements  in  technology" 
that  Withington  (WI72)  predicts  are  to  be  beneficial,  new 
logical  designs  must  provide  for  economical  movement  be- 
tween facilities  and  between  technology  generations.   Be- 
cause of  the  responsibility  delegation  in  this  constraint, 
most  of  the  interactions  mentioned  earlier  which  do  not 
appear  in  the  network  as  formally  defined,  will  be  the 
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responsibility  of  the  implementation  designers  who  will 
have  authority  to  control  them  in  any  way  that  optimizes 
their  own  goals. 

Delegation  Constraint  Dft  -  The  process 
designers  are  responsible  for  all  vir- 
tual interprocess  interactions. 

Virtual  Interprocess  interactions  are  those  pro- 
cess interactions  which  would  appear  if  the  processes  were 
being  run  as  formally  defined,  and  do  not  include  those 
additional  interactions  which  might  appear  in  the  equiva- 
lent implementations  because  the  implementation  designer 
chose  particular  physical  resources  for  his  implementation, 

Constraint  DH   follows  from  C2  and  CI.   The  imple- 
mentation designers  cannot  be  held  responsible  for  virtual 
interprocess  interactions  since  each  implementation  de- 
signer may  be  under  a  different  management  and  none  of 
the  constraints  prohibit  interactions  between  processes 
residing  in  different  network  systems.   The  network  de- 
signers cannot  be  responsible  for  all  virtual  interpro- 
cess interactions  because  they  cannot  hope  to  know  what 
all  processes  will  be  designed  to  do.   The  only  designer 
remaining  is  the  process  designer.   Even  if  it  were  not 
a  constraint  which  is  implicit  in  the  postulated  con- 
straints s  delegating  to  process  designers  the  responsi- 
bility for  all  virtual  interprocess  interations  would  be 
desirable  from  a  point  of  view  of  generality. 
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Delegation  Constraint  D5  -  If  an  implementa- 
tion designer  nas  an  urfeolvable  problem  due 
to  boundedness  which  effects  the  processes 
in  the  network s  the  effect  on  the  process 
state  structure  must  be  well-defined  so  the 
process  designers  can  ameliorate  the  conse- 
quences. . 

If  the  first  postulated  constraint  had  not  included 
bounded  systems,  constraint  D5  could  have  been  glossed 
over  by  adding  a  statement,  in  the  design,  that  the  imple- 
mentation designers  would  always  do  the  best  they  could. 
This  would  have  required  implementation  dependent  process 
transformations  without  a  common  definition  of  the  effect 
of  such  "failures"  on  the  formal  definition  of  the  network. 

Implementation  "failures"  are  solely  the  responsi- 
bility of  each  implementation  designer  under  D3,  as  long 
as  they  do  not  effect  the  virtual  processes.   When  the 
implementation  designer  declares  that  a  process  has  hit  a 
bound  (an  implementation  "failure"  has  occurred  which  the 
implementation  designer  declared  will  affect  that  process 
state),  the  "failure"  is  no  longer  solely  the  implementa- 
tion designer's  problem.   If  the  solution  were  left  up  to 
each  Implementation  designer,  each  solution  might  be  dif- 
ferent and  the  processes  might  no  longer  be  well-defined. 
Since  constraint  C^l  permits  a  process  to  delegate  to  other 
processes  authority  to  control  certain  interactions,  the 
process  which  hits  the  bound  may  not  be  responsible  for 
the  problem.   The  implementation  and  network  designers  may 
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not  have  suf fie ient  knowledge  to  decide  what  action  to 
take  to  ameliorate  the  problem,  only  the  process  designers 
may  have  the  information  necessary  to  do  it.   The  flexi- 
bility that  a  process  designer  has  to  do  so,  will  be  high- 
ly dependent  on  the  features  included  as  design  choices 
from  a  point  of  view  of  generality.   Constraint  D5  is 
intended  to  force  the  network  designer  to  include  suffi- 
cient features  in  the  design. 

Delegation  Constraint  D6  -  Network  designers 
are  responsible  for  the  initial  definition  of 
the  network  and  implicitly  for  all  evolution- 
ary paths.   Implementation  designers  are  re- 
sponsible for  the  implementation  of  the  Initial 
definition  and  for  any  potential  evolutionary 
path.   Process  desip:ners  are  responsible  for 
selecting  which  evolutionary  paths  will  be 
followed. 

Responsibility  must  be  factored  between  the  three 
designers  (C2)  and  network  modification  must  be  permitted 
(C5),  therefore  a  delegation  constraint  must  be  developed 
assigning  responsibility  for  network  evolution.   The  net- 
work designer  is  the  only  one  of  the  three  designers  which 
can  properly  be  assigned  responsibility  for  defining 
changes  in  the  initial  definition.   D2  requires  that  net- 
work designers  be  responsible  for  ensuring  the  network  is 
self-protecting,  meets  the  constraints,  and  is  formally 
defined.   This  constraint  extends  C2  to  Include  responsi- 
bility for  all  potential  network  evolution,  and  requires 
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that  the  initial  network  definition  also  define  all  poten- 
tial evolutionary  paths.   When  the  implementation  design- 
er's responsibilities  in  D3  are  extended  to  include  the 
implementation  of  modified  definitions,  it  is  imperative 
that  such  designer  be  able  to  determine  if  the  implementa- 
tion will  be  able  to  support  such  modifications  before  it- 
claims  it  has  implemented  the  network.   In  order  for  an  im- 
plementation designer  to  be  able  to  make  such  a  determina- 
tion, all  potential  paths  of  network  evolution  must  be  de- 
fined as  part  of  the  initial  network. 

It  is  possible  to  factor  the  remaining  evolutionary 
responsibilities  between  the  two  remaining  designers.   An 
implementation  designer  must  support  the  initial  network 
and  all  potential  evolutions  if  it  accepts  the  network. 
This  must  be  so  since  the  implementation  designer  is  the 
only  designer  which  can  be  responsible  for  implementing 
such  changes. 

Process  designers  must  be  delegated  the  responsi- 
bility for  determining  which  path  to  take.   The  network 
designers  fulfill  their  responsibilities  when  they  define 
the  initial  network  and  all  potential  evolutionary  paths. 
Implementation  designers  fulfill  their  responsibilities 
when  they  implement  the  initial  system,  including  modifi- 
cation operations  for  all  potential  evolutions  as  defined 
by  the  network  designers.   The  process  designer  is  free  to 
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choose  the  particular  path  of  evolution  that  it  wants  to 
take.   Under  C5»  process  designers  are  the  only  designers 
which  can  evaluate  the  potential  effects  of  such  modifica- 
tion on  the  processes.   D^  delegates  process  designers  as 
responsible  for  virtual  process  interactions.   Since  modif- 
ication of  the  network  may  cause  virtual  process  inter- 
actions (processes  may  behave  differently  after  a  modifica- 
tion than  before),  the  process  designers  must  choose  the 
modification  to  be  done.   Neither  the  network  nor  the  im- 
plementation designers  have  sufficient  knowledge  to  decide 
which  modifications  to  make.   It  is  possible  to  delegate  the 
authority  to  process  designers  to  choose  the  path,  since  it 
is  the  network  designer  which  designs  the  operators  that 
process  designers  will  cause  to  be  executed.   The  network 
designer  must  ensure  that  any  choice  of  modification  oper- 
ators will  always  be  a  permissible  one. 

Implementation  Designer  Constraints 

This  section  is  included  primarily  for  completeness. 
Since  it  is  not  the  intention  of  thin  thesis  to  look  at  im- 
plementation problems  nor  to  constrain- the  implementation 
designers  more  than  necessary,  the  constraints  dealing  with 
equivalent  system  implementation,  modification,  and  bounded- 
ness  are  sufficient  for  our  purposes.   Each  particular  im- 
plementation designer  will  have  to  develop  further  imple- 
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mentation  constraints  when  designing  an  equivalent  system. 
Responsibility  and  authority  for  meeting  the  constraints 
and  design  decisions  has  been  factored  and  future  imple- 
mentation designers  will  be  responsible  for  this  part  of 
the  design.  The  remainder  of  the  chapter  will  look  at 
further  constraints  on  the  process  and  network  designers. 

Process  Designer  Constraints 

This  section  will  look  at  some  of  the  constraints 
which  must  be  placed  on  process  designers  to  ensure  that 
their  actions  remain  within  the  postulated  constraints. 

Process  Constraint  PI  -  Processes  must  be 
arranged  in  a  tree  structure  defining  their 
hierarchy  of  responsibility  over  descendent 
processes. 

The  network  design  must  permit  processes  to  dele- 
gate to  other  processes  their  authority  to  control  process 
interactions.   The  delegating  process  always  retains  re- 
sponsibility for  that  interaction  and  authority  to  control 
the  process  to  which  it  was  delegated  (C*0.   There  are 
many  interactions  over  which  process  designers  have  author- 
ity (D4,  D5).   The  possible  process  interactions  mentioned 
earlier  included  such  things  as  birth  and  death,  allocation 
of  logical  resources,  and  logical  expectations. 

Implicit  in  constraint  CH   is  a  hierarchy  of  proces- 
ses which  defines  their  relationship  with  respect  to  re- 
sponsibility and  authority  for  controlling  other  processes. 
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Each  process  in  the  hierarchy  will  be  held  responsible  for 
its  behavior  to  processes  above  it,  even  while  delegating 
authority  to  processes  below.   There  appears  to  be  two 
alternative  ways  that  such  a  hierarchy  could  exist.   It 
could  be  as  a  general  graph  structure  with  the  various 
threads  being  the  different  responsibilities  and  authori- 
ties, or  the  more  restrictive  form  of  a  tree  structure  with 
the  threads  of  responsibility  defining  the  tree. 

First,  any  particular  chain  of  responsibility  and 
authority  cannot  be  permitted  to  double  back  on  Itself  if 
the  network  is  to  guarantee  well-defined  processes.   The 
concept  of  having  authority  over  someone  who  has  author- 
ity over  you  is  incongruous.   If  it  were  permitted,  the 
network  would  have  to  arbitrate  conflicts,  which  it  can- 
not do  because  it  dees  not  have  sufficient  knowledge  of 
what  the  processes  are  trying  to  accomplish.   The  only 
alternative  is  to  have  a  non-intersecting  thread  of  re- 
sponsibility. 

This  restricted  graph  would  still  permit  there  to 
be  more  than  one  process  responsible  for  another  process. 
If  one  process  has  more  than  one  process  responsible  for 
its  behavior,  it  would  be  impossible  to  ensure  that  there 
would  never  be  any  conflicts  of  interest  between  these 
authorities.   When  one  of  the  responsible  processes  exe- 
cuted its  authority,  it  might  affect  the  process,  for 
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which  it  is  sharing  responsibility,  in  a  way  which  would 
affect  the  interactions  over  which  the  other  process  has 
authority.   Such  conflicts  of  authority  would  require 
arbitration  which  cannot  be  allowed  If  processes  are  to 
be  well-defined. 

The  remaining  alternative  is  to  permit  processes 
to  be  related  only  in  a  tree  structure  defined  by  their 
responsibility  and  authority  over  descendent  processes. 
Since  there  is  at  most  one  immediate  responsible  agent, 
it  can  have  complete  and  unique  authority  over  the  pro- 
cesses for  which  it  is  responsible.   Although  this  is  a 
constraint  on  process  behavior,  it  produces  significant 
freedom  for  the  network  designer  because  there  is  no  need 
to  be  concerned  over  whether  or  not  a  process  has  a  cer- 
tain authority  over  another  process.   The  designer  must 
only  be  concerned  with  providing  mechanisms  which  a  parent 
process  can  use  to  exercise  its  authority  over  a  child 
process,  and  not  be  concerned  about  the  merits  of  the  use 
of  such  an  authority. 

Process  Constraint  P2  -  A  unique  root 
process  must  exist  representing  overall 
process  management. 

Constraint  D4  points  out  that  it  must  be  the  pro- 
cess designers  which  control  all  virtual  process  interac- 
tions.  The  previous  constraint  points  out  that  process 
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authority  and  responsibilities  exist  in  the  shape  of  a 
tree.   An  extension  of  the  above  arguments  leads  to  con- 
straint P2.   If  interactions  between  processes  in  differ- 
ent trees  are  to  be  permitted,  then  there  must  be  an  agent 
responsible  for  such  interactions.   Both  trees  must  there- 
fore be  sub-trees  of  some  common  ancestor.   It  would  be 
an  arbitrary  constraint  on  process  behavior  to  say  that 
two  processes  cannot  interact  if  they  exist  in  different 
trees.   Any  such  root  process  may  produce  sub-trees  which 
it  chooses  to  isolate  and  consider  independent  trees  if 
desired.   This  root  process  is  thus  unique  for  all  of  the 
processes  in  the  network. 

Process  Constraint  P3  -  No  processor  race 
conditions  can  be  permitted  to  effect  a 
process  state  transformation  during  that 
transformation. 

This  is  a  direct  consequence  of  CI  which  says  that 
the  design  must  have  well-defined  processes.   If  the  de- 
sign did  permit  processor  race  conditions  to  exist  within 
a  process  state  transformation,  the  design  would  no  longer 
satisfy  constraint  CI.   The  actual  mechanisms  to  be  used 
to  prevent  such  processor  conditions  from  occurring  are 
numerous,  and  the  ones  chosen  for  a  particular  network 
design  may  vary  according  to  the  influence  of  other  de- 
sign choices.   This  does  not  rule  out  the  inevitable  race 
conditions  arising  from  the  receipt  of  interprocess 
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messages  by  a  system  processor* 

Process  Constraint  P4  -  Operators  available 
ITo   process  designers  "affect  only  the  con- 
taining process  state. 

If  nonlocal  process  state  trans  formations  (trans- 
formations on  process  states  other  than  the  one  that  con- 
tained the  operator  that  was  executed)  were  permitted, 
constraint  CI  could  be  violated,  unless  all  such  nonlocal 
transformation  could  be  predicted,  accounted  for,  and  con- 
trolled by  a  responsible  agent. 

There  are  several  reasons  why  these  requirements 
would  be  extremely  difficult  to  guarantee  in  a  network 
design.   If  nonlocal  process  transformations  were  per- 
mitted, each  implementation  designer  might  be  forced  to 
make  sure  they  could  not  cause  processor  race  conditions 
for  the  effected  process  state.   Even  if  such  interactions 
were  in  general  constrained  to  processes  within  the  same 
system,  the  use  of  multiple  physical  processors  might  be 
difficult.   It  would  also  introduce  an  arbitrary  con- 
straint on  process  designers. 

Such  Interprocess  transformations,  if  permitted, 
would  be  a  form  of  interprocess  communication  (in  effect, 
shared  space).   Equivalent  behavior  can  be  achieved  by 
the  process  (which  would  have  initiated  the  interaction) 
transmitting  a  message  to  the  other  process.   The  message 
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then  could  cause  the  desired  transformation  as  an  opera- 
tion local  to  the  other  process  state.   The  final  network 
design ?  if  general  enough,  can  provide  these  equivalent 
operations  without  the  Inherent  overhead  that  would  be 
required  if  nonlocal  process  state  transformations  were 
permitted. 

Process  Constraint  P5  -  Multiple  processes 
may  be  transformed  in  parallel. 

Constraint  P6  is  an  obvious  consequence  of  the  first 
postulated  constraint  which  says  that  the  design  is  to  con- 
sist of  a  network  of  digital  computer  systems.   It  would  be 
inconsistent  to  expect  the  network  as  a  whole  to  operate 
sequentially.   At  a  minimum,  processes  in  different  sys- 
tems must  be  permitted  to  execute  .in  parallel.   It  is  the 
responsibility  of  the  network  designers  to  define  parallel 
transformations,  and  allow  process  designers  to  determine 
whether  or  not  to  make  use  of  this  facility.   It  would  be 
improper  at  this  time,  though,  to  make  constraint  P5  any 
stronger. 

There  is  nothing  in  the  postulated  constraints 
which  would  force  the  design  to  include  parallelism  in 
each  system  in  the  network.   Although  this  might  appear 
desirable,  it  must  be  Included  later  as  a  design  deci- 
sion, not  here  as  a  design  constraint. 

Process  Constraint  P6  -  Distribution  of 
processes  over  the  network  must  be  per- 
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mitted  and  each  process  state  must  be 
uniquely  contained  In,  at  most,  one  sys- 
tem at  a  time. 

Constraint  ?6   is  implicit  in  postulated  constraint 
CI.   It  would  make  no  sense  to  have  a  network  of  systems 
and  then  restrict  all  processes  to  exist  in  the  same  sys- 
tem.  Process  designers  should  be  able  to  choose  how  to 
distribute  processes  in  the  network,  and  constraint  ?6 
says  that  such  a  distribution  is  possible. 

A  process  would  not  be  well-defined  if  it  were 
contained  in  more  than  one  system  at  a  time  since  each 
system  would  proceed  independently  in  parallel.   There 
is  no  assumption  made  about  the  relative  speeds  of  the 
systems  in  the  network  which  means  that  nothing  could  be 
said  about  the  rapidity  with  which  the  disjoint  process 
parts  were  proceeding.   Since  a  process  is  a  sequence  of 
process  states,  the  process  becomes  not  well-defined  when 
more  than  one  system  is  transforming  it  because  the  se- 
quence of  process  states  would  not  be  well-defined.   Pro- 
cess designers  are  responsible  for  splitting  a  process 
into  multiple  processes  so  they  can  run  on  multiple  sys- 
tems. 


Process  Constraint  P7  -  Interprocess  communi- 
cation must  be  permitted  and  be  subject  to 
parental  control.  Synchronization  between 
processes  is  the  responsibility  of  process 
designers.  Processes  residing  in  different 
systems  may  be  synchronized  only  using  in- 
terprocess communication. 
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If  it  were  not  for  postulated  constraint  Ck    (pro- 
cess delegation  of  authority)  the  network  could  be  de- 
signed as  a  simple  time  sharing  system  where  no  interpro- 
cess interactions  were  permitted.   Constraint  C*J  implies 
that  there  will  have  to  be  some  interprocess  interactions 
if  the  process  designers  are  to  fulfill  their  responsi- 
bilities.  Since  process  transformations  must  be  local  to 
the  process  (P4),  the  only  remaining  means  of  meeting  con- 
straint 04  is  to  permit  interprocess  communication. 

That  such  communication  be  subject  to  parental  con- 
trol is  an  obvious  requirement,  stemming  from  constraint 
C4  and  developed  in  D4.   Process  designers  are  responsible 
for  all  virtual  interprocess  interactions  and  therefore 
must  be  responsible  for  interprocess  communication.   The 
need  for  a  process  tree  hierarchy  of  responsibility  (PI) 
puts  the  control  of  such  interactions  in  the  hands  of  the 
parent. 

Process  synchronization  is  an  interprocess  inter- 
action for  which  process  designers  must  be  responsible 
under  D4.   Network  and  implementation  designers  cannot 
always  know  if  two  processes  in  the  network  are  synchron- 
ized 4  either  intentially  or  by  accident.   The  definition 
of  digital  systems  under  constraint  CI  says  nothing  about 
the  relative  speed  at  which  process  steps  in  two  systems 
are  carried  out.   Synchronization  or  lack  of  it  between 
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systems  is  not  a  property  of  our  network  since  it  depends 
on  the  implementation.   The  particular  allocation  of  hard- 
ware used  by  implementation  designers  for  its  optimal 
equivalent  systems  (D3)  might  have  multiple  logical  sys- 
tems implemented  on  one  physical  system,  or  might  use  mul- 
tiple physical  systems  to  implement  one  logical  system. 
Without  placing  an  arbitrary  constraint,  to  implement 
either  synchronous  or  asynchronous  systems  only  (which 
we  choose  not  to  do),  synchronization  between  processes 
in  different  systems  can  only  be  ensured  by  the  processes 
themselves  using  interprocess  communication. 

Process  constraint  P8  -  An  "accountable  ob- 
ject71 chain  must  exist,  and  processes  must 
be  able  to  restrict  use  of  these  accountable 
objects  when  sub-allocated. 

Accountable  objects  are  logical  resources  which 
processes  may  allocate  to  their  children ,      The  network 
design  provides  services  for  the  accounting  of  these  ob- 
jects, including  the  return  of  them  if  a  parent  wishes 
them  back  and  enforcing  constraints  on  their  use. 

A  process  tree  of  responsible  agents  alone  does 
not  completely  describe  the  implications  of  postulated 
constraint  C4.   It  does  not  provide  sufficient  services 
for  a  process  designer  to  use  to  control  all  virtual  in- 
terprocess interactions.   There  are  several  interactions 
with  respect  to  logical  resources  which  the  previous 
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constraints  still  permit  to  go  uncontrolled.   If  a  network 
is  to  permit  processes  to  delegate  authority,  then  this 
authority  is  a  logical  resource  whose  accounting  and  sub- 
allocation  is  something  that  a  parent  may  need  to  control. 
The  constraints  make  no  assumptions  about  a  child's  cooper- 
ation with  its  parent.   A  special  mechanism  must  therefore 
be  provided  which  permits  the  parent  to  fulfill  its  respon- 
sibilities even  if  a  child  becomes  uncooperative .   The 
process  tree  defines  responsibility ,  but  does  not  constrain 
how  deep  the  tree  may  be  or  how  many  children  a  particu- 
lar process  may  have. 

Although  it  is  the  responsibility  of  the  process 
designers  to  decide  what  and  how  much  authority  to  give 
to  a  child,  the  network  design  must  provide  remote  en- 
forcement services  for  accountable  objects.   At  this  point- 
it  is  not  important  what  is  being  passed,  but  only  that 
certain  accountable  information  must  be  passed.   For  ex- 
ample, communication  must  be  subject  to  parental  control 
(P7)  and  certain  accountable  information  may  be  necessary 
to  accomplish  this.   Since  the  children  may  not  be  cooper- 
ative, the  network  must  provide  use  restrictions  and  ac- 
counting mechanisms,  which  may  be  invoked  to  protect  these 
objects  from  the  actions  of  a  child. 

These  items  (whatever  they  may  logically  represent) 
become  accountable  objects  to  the  network.   Since  there 
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are  no  restriction*?  on  how  deep  a  tree  nay  be  or  how  many 
children  a  particular  process  may  have,  a  constraint  is 
required  which  provides  sufficient  facilities  to  process 
management  to  control  the  use  of  these  objects*   Given 
the  existence  of  an  accountable  object,  the  network,  if 
it  is  to  perform  its  functions,  must  be  able  to  locate 
the  object.   The  network  design  must  provide  for  an  ac- 
counting chain  (to  the  object  from  the  process  responsible 
for  it)  which  is  not  subject  to  the  desires  of  the  child 
process.   In  addition,  if  a  process  designer  is  to  dele- 
gate some  of  its  authority,  then  mechanisms  must  be  pro- 
vided which  allow  restriction  of  the  use  of  these  account- 
able objects  in  addition  to  just  accounting  for  them. 

Network  Designer  Constraints 

The  previous  section  developed  some  of  the  con- 
straints on  the  system  design  due  to  process  designer 
responsibilities  which  can  be  derived  from  the  five  postu- 
lated constraints.   This  section  will  look  at  some  of  the 
constraints  which  must  exist  to  permit  the  network  de- 
signer to  fulfill  its  responsibilities. 


Network  Constraint  Nl  -  The  network  designer 
is  responsible  for  providing  a  set  of  invari- 
ant names  which  can  be  used  by  the  process  de- 
signers for  communication  and  control. 

Since  different  implementation  designers,  if  not 
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restricted,  might  use  local  names  for  control  and  commun- 
ication >  process  communication  might  become  implementation 
dependent.   If  process  designers  created  the  names,  they 
also  might  not  be  consistent  in  name  creation.   The  only 
common  designer  capable  of  defining  a  set  of  invariant 
names,  which  can  be  used  by  the  processes  for  communica- 
tions and  control,  is  the  network  designer. 

Network  Constraint  N2  -  The  network  de- 
signers  'aire  responsible  for  changes  in  the 
network  formal  definition. 

The  fifth  postulated  constraint  introduces  the 
possibility  of  augmentation  into  the  design,  D2  desig- 
nates the  network  designer  as  responsible  for  the  net- 
work's definition,  and  D6  designates  the  network  designer 
as  responsible  for  all  evolutionary  paths.   The  network 
designer  must  also  fulfill  its  responsibility  by  con- 
straining evolutionary  changes  in  the  formal  definition, 
before  the  implementers  can  actually  augment  the  system. 

Network  Constraint  M3  -  Sufficient  services 
must "be  provided,  by  the  network  designers, 
for  the  process  designers  to  accomplish  their 
purpose,  including  resource  accounting  and 
intersystem  communication. 

The  particular  services  provided  by  the  network 
designers  will  be  designed  according  to  how  they  deem 
the  network  will  be  used.   Resource-  accounting  and  inter- 
system communication  are  services  already  mentioned  spe- 
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cifically,  but  there  will  be  many  more.   This  is  a  require- 
ment since  each  designer  must  have  sufficient  authority  to 
restrict  the  effects  of  the  interactions  for  which  it  is 
responsible.   If  the  process  designers  are  to  be  respon- 
sible for  all  interprocess  interactions,  then  the  network 
must  provide  common  services  through  which  they  may  exer- 
cise this  authority,, 

Network  Constraint  UH   -  Network  modification 
operators  are  meta-operators  and  must  first 
ensure  the  modification  does  not  violate  any 
of  the  postulated  constraints  and  then  either 
act  as  a  no-op  if  it  is  one  of  the  permissible 
paths  of  evolution  or  fault  if  it  is  not. 

Network  modification  operator  -  A  formally  defined 
operator  which  the  process  designers  can  cause  to  be  executed. 
It  is  intended  to  cause  the  network  definition  to  be  modi- 
fied and  then  implemented  by  using  locally  defined  procedures 

Meta-opsrator  -  An  operator  whose  effect  i3  not 
represented  by  a  change  in  the  process  state.   (In  this 
case  it  changes  the  network  definition. ) 

No-op  -  An  operator  which  does  not  change  the  proc- 
ess state  other  than  to  advance  the  "program  counter." 

It  is  clear  that  such  modification  operators  must 
be  meta-operators  since  they  operate  on  the  network  defin- 
ition and  not  on  the  process  state.   That  the  operators 
must  prove  the  modification  does  not  violate  any  of  the 
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postulated  constraints  follows  from  the  delegation  of  re- 
sponsibility constraint  D6,  where  network  management  is 
responsible  for  all  evolutionary  paths.   The  only  way  that 
the  network  management  can  fulfill  this  responsibility  is 
to  design  the  operators  so  they  ensure  the  modification 
does  not  violate  the  constraints. 

The  results  of  process  management  executing  such  an 
operator,  must  be  either  a  no-op  or  a  fault  in  the  execut- 
ing system.   The  execution  of  a  modification  operator  may 
cause  interactions  which  are  the  responsibility  of  each 
of  the  three  designers.   The  definition  must  be  changed, 
the  new  definition  must  be  implemented,  and  finally  the 
process  must  be  told  it  succeeded  or  not. 

If  the  operation  had  any  affect  on  the  process  it- 
self other  than  fault  or  no-op,  then  the  implementation 
management  would  have  to  ensure  that  the  process  remained 
well-defined.   All  system  steps  would  have  to  be  designed 
and  implemented  so  the  execution  of  a  modification  opera- 
tor during  one  of  the  steps  would  leave  the  executing  pro- 
cess well-defined  (this  might  be  possible),  but  even  worse, 
it  would  have  to  leave  all  other  processes  (also  executing 
during  that  step)  well-defined.   This  is  clearly  not  the 
responsibility  of  either  the  process  or  implementation 
designers . 

Since  the  network  designer  does  not  have  complete 


knowledge  of  what  either  of  these  two  designers  will  al- 
ways be  doing,  the  only  guaranteed  non-race  situation  is 
to  consider  it  a  no-op  in  process  transformations.   The 
process  executes  the  operator  and  either  goes  on  with  a 
no-op  or  faults  (well-defined  operations  during  that 
system  step).   The  definition  is  either  changed  or  not 
depending  on  the  validity  of  the  operation,  and  finally 
the  implementation  designer  changes  the  implementation 
between  system  steps  when  all  processes  are  not  undergoing 
transformations  and  then  starts  the  next  system  step  using 
the  new  definition. 

Network  Constraint  N5  -  The  effects  of 
network  evolution,  ether  than  the  addition 
of  a  new  system  to  the  network,  must  be 
local  to  the  system  within  which  the  oper- 
ator was  executed. 

This  constraint  follows  directly  from  the  fact  that 
we  are  interested  in  digital  systems  (CI),  the  factoring 
of  responsibility,  and  maintaining  well-defined  evolu- 
tionary processes.   To  say  that  the  effects  of  evolution 
were  other  than  local  to  the  system  in  which  the  operator 
was  executed  would  require  synchronization  between  two 
systems,  a  violation  of  the  concept  of  digital  system. 
This  would  not  rule  out,  of  course,  a  process  in  one  sys- 
tem executing  an  operator  which  caused  a  message  to  be 
transmitted  to  another  process  in  another  system.   That 
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process  could  then  execute  the  modification  operator  and 
cause  that  system  to  be  modified  since  the  final  modifica- 
tion Is  local.   The  exact  procedure  again  will  depend  en 
the  particular  modifying  operators  provided  by  the  network 
designers.   The  addition  of  a  new  system  cannot  be  con- 
sidered locaj  since  there  is  no  such  system  in  the  first 
place. 

Network  Constraint  N6  -  The  network  design 
must"1  Lt  process  designers  to  limit  the 
effects  of  a  network  modification  operator 
to  the  process  executing  it.  Process  de- 
signers must  be  able  to  uniquely  control 
the  right  to  execute  non-commuting  modifi- 
cation operators  (if  any  exist). 

Constraint  N6  follows  directly  from  postulated  con- 
straints CI  and  C5.   Process  designers  must  have  responsi- 
bility and  authority  to  control  the  effects  of  network 
definition  modification  on  the  process  interactions  for 
which  the  process  designer  has  been  designated  responsi- 
bility.  This  is  not  quite  strong  enough  to  guarantee  the 
well-defined  processes  as  required  by  CI.   Because  the 
modification  operator  is  really  a  meta-operator  (N'l), 
there  could  be  interactions  due  to  two  processes  simul- 
taneously executing  non-commuting  modification  operators 
which  would  result  in  non-well-defined  processes  or  sys- 
tem. 

C5  as  stated  could  permit  the  effects  to  be  limited 
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to  the  two  processes  executing  the  modification  operator, 
but  the  resulting  network  definition  might  be  different 
than  either  one  of  the  processes  expected.   In  order  to 
guarantee  that  all  processes  will  be  well-defined,  pro- 
cess designers  must  be  able  to  limit  the  effects  of  the 
execution  of  a  modification  operator  to  the  process  exe- 
cuting that  operator. 

As  a  consequence  of  permitting  the  processes  to  sub- 
allocate  their  responsibilities  the  right  to  execute  non- 
commuting  modification  operators  (if  they  are  permitted) 
must  be  controlled.   If  non-commuting  operators  exist, 
then  two  processes  executing  such  modification  operators 
could  affect  each  other  in  a  way  that  would  make  the  oper- 
ation have  nonlocal  effects  and  possibly  producs  processes 
which  are  not  well-defined. 
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Programming  generality  is  the  inde- 
pendence of  an  algorithm  from  the  environ- 
ment in  which  it  operates  (Denning,  P.J.  • 
De68,  p.  6). 


CHAPTER  3 
NETWORK  STRUCTURE  DESIGN 

Introduction 

The  primary  goal  of  this  thesis  is  the  d< 
and  formal  definition  of  a  general  machine  in<    idi  nt  net- 
work design  which  will  support  potentially  uncooperative 
processes.   In  the  previous  chapter  a  set  of  constraints 
were  developed  which  are  intended  to  permit  network  manage- 
ment problems  (relevant  to  the  control  of  uncooperative  pro- 
cesses) to  be  solved.   Boundedness  and  network  evolution 
were  also  included.   Network  designers  are  responsible  for 
the  design  end  formal  definition  of  the  network.   Implement- 
ation designers  are  responsible  for  implementing  locally 
optimal  equivalent  systems.   Process  designers  are  responsi- 
ble for  controlling  all  interprocess  interactions  between 
the  processes  in  the  virtual  network,  including  those  due 
to  suballocation  of  the  control  of  interprocess  interactions. 

This  chapter  will  informally  develop  the  major  design 
choices  relevant  to  process  state  structures  and  the  trans- 
formations to  be  carried  out  on  them.   Within  the  bounds  of 
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the  constraints,  many  network  designs  could  be  produced, 

some  of  which  would  not  provide  what  we  feel  is  sufficient 

process  generality*   This  chapter  presents  those  design 

decisions,  relating  to  such  generality,  which  the  networks 

defined  by  this  design  should  provide.   The  design  choices 

will  be  explained  and  where  necessary  shown  to  be  consistent 

with  the  constraints  of  the  previous  chapter. 

Since  network  modification  must  be  permitted,  a  mini- 
mal system  will  be  presented  from  which  any  particular  net- 
work may  evolve.   The  process  designers  determine  which 
modification  operators  will  be  executed,  and  therefore  re- 
tain significant  control  of  the  attributes  of  a  particular 
network.   A  minimal  initial  definition  also  has  the  advantage 
of  requiring  the  network  design  to  Include  at  least  those 
network  modification  operators  which  are  necessary  to  evolve 
interesting  networks  from  the  initial  system.   Although  the 
sequence  of  presentation  did  not  effect  the  validity  of  the 
constraints,  the  same  cannot  be  said  for  the  design  decisions 
presented  here.   The  development  is  intended  to  be  complete 
enough  to  permit  the  reader  to  understand  the  essential 
characteristics  of  the  network  in  all  respects  except  its 
final  representation.   A  formal  definition  of  the  network 
will  be  found  in  Appendix  C. 

There  are  several  informal  design  principles  which 
have  been  used  in  this  chapter.   An  attempt  has  been  made  to 
provide  facilities  which  process  designers  can  use  to  con- 
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struct  processes  which  implement  their  decisions  concerning 
the  control  of  their  application  processes.   The  network  de- 
sign should  not  build  in  particular  strategies  whenever  it 
can  be  avoided y   particularly  if  it  limits  the  freedom  of 
process  designers.   The  tools  provided  should  be  useful  and 
convenient  so  that  interesting  applications  can  be  produced 
and  properly  managed.   Each  process  in  the  network  should  be 
able  to  make  finite  progress,  independent  of  what  other  pro- 
cesses in  the  network  are  doin 

In  addition  to  providing  a  rich  programming  environ- 
ment, the  design  should  be  general  enough  to  be  used  as  a 
model  to  compare  current  systems,  and  should  be  an  easy 
framework  for  communicating  ideas.   To  accomplish  this  the 
concepts  should  provide  generality  of  expression  rather  than 
a  list  of  options  which  tend  to  be  confused.   In  order  to 
maintain  generality,  the  introduction  of  features  reflecting 
specialization  for  specific  applications  or  particular  phy- 
sical assets  should  be  minimized.   Where  possible,  placing 
constraints  on  the  design  of  the  programming  languages  should 
be  deferred  until  they  are  required. 

Although  efficiency  with  respect  to  current  systems 
is  not  a  primary  goal,  process  generality  features  should 
not  be  Introduced  without  hope  of  reasonable  implementation. 
Invariant  network  features  should  be  identified  so  imple- 
mentation designers  can  exploit  them  for  efficient  imple- 
mentation.  Intuitive  notions  of  efficiency  should  be  brought 
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into  play  when  choosing  between  design  decisions,  particu- 
larly if  they  concern  implement at ion  on  current  systems. 

Subprocessor  and  Expression-State 

Design  decision  Al  -  Each  system  processor  in 
the  network  will  contain  a  set  of  identifiable 
subprocessors  including  at  least  the  following 
three:   OF  (General  Programmable),  AO  (Account- 
able Object),  and  PR  (Process  state  Receive  and 
transmit) . 

A  subprocessor  is  defined  as  an  operator  of  the  sys- 
tem processor  that  is  applied  to  a  single  process  state. 
It  may  be  designed  to  produce  an  arbitrarily  complex  pro- 
cess transformation,  using  only  information  within  that 
process  state*   Process  designers  request  the  system  pro- 
cessor to  apply  a  particular  subprocessor  to  a  particular 
process  state.   The  execution  of  a  subprocessor  only  trans- 
forms the  process  state  to  which  it  is  being  applied  and 
does  not  involve  message  transmission  or  receipt. 

All  operators  of  the  system  processor,  including  sub- 
processors,  which  are  to  be  applied  during  a  particular 
system  step,  are  applied  in  parallel.   The  system  step  does 
not  complete  until  all  operators  being  applied  during  that 
step  have  completed.   The  system  processor  performs  all  oper- 
ations not  local  to  the  process  state  (the  transformation 
involves  information  in  addition  to  that  contained  in  the 
process  state).   For  example,  it  delivers  messages  to  a 
process  state  for  disposition  by  a  subprocessor,  and  dis- 
patches messages  after  they  are  generated  by  a  subprocessor. 
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The  introduction  of  the  concept  of  sub-processor  into 
the  network  design  provides  a  freedom  to  delegate  responsi- 
bility for*  the  design  of  the  languages  to  be  interpreted  by 
the  subprocessor  to  future  subprocessor  designers  with  a 
minimum  of  constraints.   The  network  designer  still  retains 
responsibility  for  designing  the  network  so  process  design- 
ers can  control  interprocess  interactions.   The  subprocessor 
thus  becomes  the  user  programmable  part  of  each  system  pro- 
cessor.  The  design  of  the  language  interpreted  by  a  sub- 
processor  will  define  the  way  processes  may  be  formed  by 
defining  the  transformations  on  process  states. 

Since  processes  are  not  assumed  cooperative,  it  is 
convenient  to  limit  the  effects  of  the  interpretation  of 
such  languages.   The  use  of  a  subprocessor,  whose  operations 
can  only  be  local  to  a  process  state,  permits  this.   The 
system  processor  then  performs  all  operations  not  local  to 
a  process  state  and  can  be  designed  to  provide  a  well- 
defined  interface  for  all  operations  which  are  not  strictly 
local  to  a  process  state.   The  network  designer  need  only 
constrain,  not  define,  subprocessor  operations  which  are 
always  local  to  a  process  state.   All  non-local  services  of 
the  system  processor  can  be  invoked  implicitly  by  the  sub- 
processors,  and  be  invariant  across  the  network. 

An  equivalent  system  processor  could  have  been  de- 
signed which  did  not  contain  subprocessors.   It  could  be 
augmented  with  equivalent  transformation  operators  and 
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proper  sequencing  and  control  functions  to  produce  processes 
equivalent  to  those  produced  using  subprocessors.   Subpro- 
cessors  simplify  the  network  design.   Without  them,  the  sys- 
tem processor  is  cluttered  with  details  which  are  not  rele- 
vant to  its  basic  operations  of  providing  services  not  local 
to  a  process  state.   Understanding  those  operations  which 
would  have  been  logically  grouped  as  a  subprocessor  is  made 
more  difficult  because  of  the  additional  potential  inter- 
actions they  would  have  with  the  other  operators  of  the  sys- 
tem processor.   Since  a  process  state  is  observable  once 
each  system  step,  the  observed  process  would  be  cluttered 
with  the  intermediate  steps  which  would  have  been  hidden  by 
a  subprocessor, 

The  designer  of  a  subprocessor  has  certain  freedoms 
that  would  not  be  present  if  all  of  the  subprocessor  func- 
tions had  to  be  integrated  into  the  system  processor.   Only 
the  system  processor,  and  the  interactions  of  a  subprocessor 
with  it,  need  be  understood  by  that  subprocessor  designer. 
Nothing  need  be  known  about  the  way  other  subprocessors 
operate  during  execution.   It  is  assumed  that  all  network 
designers  will  meet  the  constraints  and  design  decisions. 
Without  subprocessors,  their  responsibilities  would  include 
a  much  larger  part  of  each  system.   All  systems  in  the  net- 
work would  not  necessarily  provide  the  same  set  of  subpro- 
cessors.  The  interactions  to  be  prepared  for,  if  the  design 
did  not  use  subprocessors,  would  therefore  not  necessarily 
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be  the  same  in  each  system,  complicating  the  problem  even 
more.   Many  more  constraints  and  design  decisions  would  have 
to  be  introduced  into  the  network  to  ensure  that  it  supported 
only  well-defined  processes. 

A  subprocessor  designer  need  not  be  concerned  with 
having  its  operations  interrupted  by  incoming  messages,  or 
the  effect  of  the  transmission  of  a.  message  to  another  pro- 
cess whose  subprocessor  is  in  the  middle  of  a  process  step, 
Nonlocal  operations  are  done  by  bhe  system  processor.   Buf- 
fering or  other  techniques  can  be  used  by  a  subprocessor 
designer  during  the  execution  of  a  process  step  since  such 
information  cannot  be  affected  by  anything  outside  the  sub- 
processor  until  the  step  has  been  completed.   The  network 
designer  thus  guaranties  the  locality  of  process  state 
transformations  with  minimal  constraints  on  subprocessor 
designers. 

Subprocessors  are  applied  by  the  system  processor  to 
the  process  states f  in  the  same  manner  as  any  other  opera- 
tors, and  must  be  identifiable  (recognizable  and  named) 
within  the  system  processor.   Process  designers  must  have 
control  over  the  sequencing  of  subprocessor  applications, 
uniquely  specifying  the  different  subprocessors  to  be 
applied.   The  system  processor,  if  the  subprocessors  are 
identifiable,  can  be  designed  to  apply  the  proper  subpro- 
cessor on  command  by  process  designers  without  caring  what 
the  many  different  processes  In  the  network  are  intending 
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to  do. 

Each  system  in  the  network  will  have  at  least  a  GP, 
AO,  and  PR  subprocessor  which  are  common  to  all  systems. 
The  network  designer  cannot  hope  to  know  all  the  subpro- 
cessors present  and  future  process  designers  will  want  to 
use.   Therefore,  although  these  three  common  subprocessors 
provide  all  initial  network  services,  it  would  be  arbitrary 
to  define  a  set  of  subprocessors  which,  would  be  available 
at  each  system  in  the  network  and  then  prohibit  the  intro- 
duction of  any  others.   One  of  the  purposes  of  introducing 
subprocessors  into  the  network  is  to  defer  to  future  de- 
signers the  development  of  subprocessors  and  the  languages 
they  interpret.   The  at  least  in  design  decision  Al  is  in- 
tended to  permit  the  introduction  of  additional  subproces- 
sors.  One  of  the  network  evolutionary  steps  that  the  design 
will  permit  is  the  introduction  of  new  subprocessors  into 
particular  systems  of  the  network. 

The  GP  subprocessor  is  the  general  programmable  sub- 
processor  which  is  common  to  each  system  in  the  network.   It 
provides  all  initial  network  services  to  process  designers. 
The  GP  is  programmable  to  ensure  that  process  designers  may 
invoke  services  to  create  useful  processes,  thus  fulfilling 
network  management's  responsibilities  to  provide  for  pro- 
grammable systems.   The  GP  must  provide  all  such  services 
by  interpreting  a  very  general  programming  language  since  it 
may  be  the  only  programmable  subprocessor  in  some  systems. 
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Without  at  least  one  common  programmable  subprocessor  avail- 
able at  each  system,  process  transportability  would  not  be 
very  useful.   The  GP,  since  it  is  common,  will  provide  pro- 
cess designers  with  one  language  whose  interpretation  is  in- 
variant in  all  systems  in  the  network.   If  a  particular  sys- 
tem provides  for  additional  programmable  subprocessors ,  the 
process  designer  must  make  the  choice  of  whether  or  not  to 
use  the  GP.   The  GP  is  therefore  not  the  "universal"  lan- 
guage, but  only  a  guaranteed  "common"  language. 

The  AO  subprocessor  is  common  to  all  systems  in  the 
network  and  has  been  delegated  the  job  of  fulfilling  all 
network  responsibilities  with  respect  to  accountable  ob- 
jects (N3  and  P8).   By  delegating  these  responsibilities 
to  a  subprocessor  Instead  of  fulfilling  thorn  as  part  of 
each  system  processor  design,  the  network  designer  is  able 
to  defer  binding  the  structures  used  for  accountable  objects, 
while  still  having  sufficient  guarantees  that  the  network 
responsibilities  will  be  satisfied.   The  network  design  can 
proceed  without  getting  involved  in  the  semantic  and  syn- 
tactic problems  involved  with  accountable  objects  and  their 
use.   The  AO  subprocessor  will  not  be  programmable  in  the 
general  sense  of  the  word,  but  will  provide  services  to  the 
programmable  subprocessors  of  the  network.   It  must  be  de- 
signed to  carry  out  its  responsibilities  cooperatively  with 
respect  to  accountable  objects,  even  though  particular  pro- 
cesses may  try  to  be  uncooperative. 
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The  final  subprocessor  which  must  be  common  to  each 
system  in  the  network  is  the  PR  (Process  state  Receive  and 
transmit)  subprocessor.   The  PR  will  carry  out  transforma- 
tions on  the  PR  process,  whose  function  will  be  to  re- 
ceive both  process  states  from  other  systems  and  requests 
for  process  creation  and  transmission  from  processes  in 
its  own  system.   If  the  request  is  to  create  a  new  pro- 
cess or  if  it  is  a  process  state  from  another  system  and 
the  process  state  is  valid  to  run  in  that  system,  the  PR 
process  requests  the  system  processor  to  start  the  process. 
If  the  request  is  to  move  a  process  to  another  system,  the 
FR  process  requests  the  system  processor  to  transmit  the 
process  state  to  the  PR  process  in  the  destination  system. 

Validation  of  requests  for  process  creation  and 
movement  is  simplified  by  requiring  that  within  the  network 
systems  only  the  AO  subprocessor  be  able  to  generate  them. 
Since  the  AO  subprocessor  is  designed  to  be  cooperative, 
the  PR  can  be  designed  to  assume  all  requests,  even  from 
other  systems  within  the  network  are  valid,  provided 
communication  is  designed  so  the  source  is  known.   Re- 
quests from  foreign  systems  would  present  a  verification 
problem  since  nothing  may  be  known  about  such  foreign 
systems.   A  PR  process  will  therefore  be  designed  to  re- 
ceive requests  only  from  processes  within  its  system  or 
from  other  PR  processes  in  the  other  systems  of  the  net- 
work.  The  PR  functions  can  easily  be  defined  as  a  sub- 
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processor  and  delegated  to  future  designers.   An  example 
PR  subprocessor  is  defined  in  Appendix  c. 

§®s^^clslonJV2-  A  process  state  is  de- 
fined by  a  set  of  identifiable,  typed,  possi- 
bly related  expression-states,  and  associated 
information  necessary  for  both  subprocessor 
allocation  and  interprocess  interactions. 

A  process  state  will  have  identifiable  substates 
which  will  be  called  expression-states.   Expression-states 
contain  the  stats  information  associated  with  the  execution 
of  a  subprocessor.   Program  interpretation  information 
along  with  data  structures  and  their  associated  values  would 
be  included.   Expression-states  are  accessed  and  transformed 
by  subprocessors  when  they  are  applied  to  the  process  state. 

Without  the  requirement  that  expression-states  be 
identifiable,  subprocessors  might  not  be  able  to  distinguish 
one  expression-state  from  another.   Accidental  subprocessor 
operations  on  expression-states  other  than  the  ones  it  should 
be  accessing  might  occur,  with  possibly  undefined  results. 
In  order  to  ensure  that  illegal  process  states  did  not  occur, 
the  design  would  have  to  place  additional  constraints  which 
would  restrict  the  generality  available  to  process  designers. 
We  could  have  said  that  expression-states  could  not  interact. 
There  would  then  be  no  need  for  more  than  one  expression- 
state  in  a  process  state  at  a  time.   This  solution  would  not 
allow  many  conventional  relationships  such  as  that  maintained 
by  coroutines. 
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We  could  have  restricted  the  process  state  from  con- 
taining more  than  one  bype  of  expression-state.   The  whole 
process  state  structure  could  have  then  been  made  subprc- 
cessor  type  dependent.   The  state  structure  recognized  by 
the  subprocessor  could  then  be  made  to  define  different 
expression-states*   The  system  processor  would  only  have  to 
know  which  subprocessor  to  apply  and  the  subprocessor  de- 
signer would  define  all  permissible  operations  on  the  pro- 
cess state.   Although  this  is  simpler,  it  is  not  as  general 
as  permitting  multiple  kinds  of  related  expression-states 
to  exist  within  one  process  state. 

Once  the  design  permits  a  process  state  to  contain 
multiple  kinds  of  expression-states,  all  subprocessors  can 
no  longer  be  guaranteed  to  recognize  all  of  them.   For  exam- 
ple, a  process  state  might  contain  three  kinds  of  expression- 
states  related  in  a  tree  structure  (root  and  two  branches). 
The  appropriate  subprocessor  for  either  branch  might  be  able 
to  interpret  the  root  expression-state,  but  not  the  expres- 
sion-state at  the  other  branch. 

If  the  design  is  to  support  well-defined  processes, 
each  subprocessor  must  recognize  when  it  has  referenced  a 
new  expression-state.   This  prevents  a  subprocessor  from 
accidentally  transforming  an  expression-state  because  an 
expression-state  boundary  was  unwittingly  crossed.   The 
network  design  must  therefore  provide  expression-state  de- 
limiters in  a  process  state  so  that  it  is  possible  to  recog- 
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nize  all  of  the  expression-states  contained  in  It. 

Expression-state  recognition  alone  does  not  guarantee 
well-defined  processes.   A  subprocessor  independent  method 
of  identifying  an  expression-state  as  to  its  kind  is  also 
needed.   There  is  no  way  to  guarantee,  using  independently 
designed  expression-states,  that  all  subprocessors  can  de- 
termine if  a  particular  expression-state  is  one  of  the  types 
it  can  interpret „   The  network  defined  process  state  struc- 
tures must  therefore  provide  that  a  type  be  associated  with 
each  expression-state.   A  subprocessor  when  applied  to  a 
process  state,  can  then  identify  all  of  the  expression- 
states  and  know  which  ones-  it  can  interpret.   As  long  as  an 
expression-state  is  identifiable,  typed  substate  of  a  pro- 
cess state,  no  further  constraints  need  be  placed  on  its 
internal  structure,  this  is  left  up  to  the  individual  sub- 
processor  designers. 

A  process  state  contains,  in  addition  to  a  set  of 
expression-states,  the  information  necessary  for  the  system 
processor  to  carry  out  subprocessor  allocation  and  inter- 
process interactions.   Since  both  of  these  operations  in- 
volve operations  external  to  a  process  state  they  must  be 
performed  by  the  system  processor  (constraint  PlJ ) .   The  sys- 
tem processor  therefore  must  have  access  to  the  necessary 
information.   Such  information  cannot  be  maintained  internal 
to  the  expression-states  because  the  system  processor  might 
not  be  able  to  recognize  it.   Expression-state  structures 
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are  defined  by  the  subprocessor  designers  and  not  the  system 
processor  designer.   Therefore,  the  information  must  be  part 
of  the  network  defined  process  state  structure  external  to 
expression-states. 

A2_j_l  -  Subprocessor  access  to  structures  of 
any "other  type  of  expression-state  must  not 
violate  the  conventions  of  the  other  expres- 
sion-state's designer. 

Identification  of  expression-states  by  type  is  not 
sufficient  to  guarantee  well-defined  processes.   The  access 
of  subprocessors  to  other  than  their  own  type  of  expression- 
states  must  be  constrained  so  those  expression-states  are 
not  left  in  an  improper  form*   The  designer  of  an  expression- 
state  defines  the  conventions  that  are  to  be  followed  and 
the  designer  of  any  subprocessor  which  is  to  access  it  must 
follow  these  conventions. 

It  would  be  impossible  for  any  designer  other  than 
the  expression-state  designer  to  decide  on  the  conventions 
to  be  followed  when  a  subprocessor  accesses  each  type  of 
expression-states  since  no  constraints  have  been  placed  on 
their  design  in  the  first  place.   The  network  design  must 
therefore  delegate  to  that  same  designer  the  responsibility 
for  deciding  what  conventions  must  be  followed  upon  another 
subprocessor  access  to  the  expression-state.   The  designer 
of  each  subprocessor  is  then  responsible  for  ensuring  that 
the  proper  conventions  are  followed  by  it  on  access  to  a 
particular  type  of  expression  state  and  that  it  does  not 
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transform  any  expression-state  type  it  is  not  supposed  to 
access. 

Control-Point 

Design  decision  A3  -  "Control-Points"  are 
accountable  object  . 

Control-Points  like  expression-states  will  be  sub- 
states  of  a  process  state.   They  will  have  associated  with 
them  the  information  necessary  for  the  system  processor  to 
carry  out  its  services  with  respect  to  the  containing  pro- 
cess state.   Control-points  are  an  expression-state  inde- 
pendent interface  between  subprocessors  and  the  system  pro- 
cessor.  Subprocessor  allocation  and  interprocess  interac- 
tion information  can  be  associated  with  them  and  therefore 
be  maintained  external  to  expression-states.   The  design 
and  use  of  such  Information  can  thus  be  kept  independent  of 
the  design,  and  use  of  expression-states. 

The  concept  of  control-points  as  part  of  a  process 
state  will  simplify  the  design  of  the  system  processor.   The 
design  of  operations  on  the  process  state  information  asso- 
ciated with  control-points  can  be  separated  from  the  lan- 
guage dependent  transformations  on  the  information  contained 
in  expression-states.   Since  control-points  are  part  of  the 
process  state,  their  information  can  be  operated  upon  local- 
ly by  a  subprocessor  operating  on  that  process  state.   In 
addition,  the  system  processor  can  safely  access  the  control- 
point  state  information  because  the  state  structure  is  part 
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of  the  network  design  and  the  same  in  all  process  states. 
Control-points  are  also  well-defined  and  therefore  can  be 
interpreted  by  all  system  processors  in  the  network. 

The  next  several  sections  will  describe  the  role  con- 
trol-points play  in  subprocessor  allocation  and  interprocess 
communication.   It  will  not  be  possible  to  transform  an  ex- 
pression-state, and  hence  a  process  state,  without  a  control- 
point.   Competition  for  control-points  is  therefore  a  type 
of  interaction  between  processes  for  which  process  designers 
must  be  held  responsible.   They  are  the  only  agents  with 
access  to  sufficient  information  to  manage  such  interactions. 

The  AO  subprocessor  provides  the  only  network  guar- 
anteed mechanism  through  which  process  designers  can  sub- 
allocate  control-points  in  the  process  tree,  while  main- 
taining the  ability  to  restrict  their  use  or  recover  them. 
As  long  as  control-points  are  accountable  objects,  the  AO 
subprocessor  will  account  for  them  and  enforce  a  parent's 
requirements  placed  on  a  child's  use  of  them. 

A3.1  -  Individual  control-points  may  be  paired 
wTUTT  individual  expression-states  and  more 
than  one  such  pair  may  exist  in  a  process 
state  at  one  time. 

When  paired  with  an  expression-state,  the  control-point 
names  that  expression-state  for  all  system  processor  pro- 
vided services.   Pairing  a  control-point  with  a  particular 
expression-state  permits  process  designers  to  distinguish 
it  (for  the  system  processor)  from  all  the  other  expression- 
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states  in  the  process  state.   Although  expression-estates  are 
typed,  they  are  not  really  named  since  there  may  be  more  than 
one  expression-state  of  a  given  type  in  a  process  state. 
Pairing  a  control-point  with  a  particular  expression-state 
permits  process  management  to  use  the  control-point's  state 
to  direct  the  system  processor  in  performing  its  operation 
with  respect  to  that  particular  expression-state.   As  will 
be  seen  later,  this  is  particularly  convenient  with  respect 
to  interprocess  communication. 

Having  multiple  expression-state/control-point 
(ES/CP)  pairs  within  a  process  state,  permits  a  process  de- 
signer to  select  for  interpretation  more  than  one  expression- 
state  at  a  time.   Since  control-points  have  associated  with 
them  all  the  information  necessary  to  direct  the  subproces- 
sor  in  carrying  out  all  operations  which  are  not  local  to  a 
process  state,  they  must  contain  the  information  necessary 
for  subprocessor  allocation.   Multiple  ES/CP  pairs  permit 
more  than  one  expression-state  at  a  time  to  be  involved  in 
interprocess  communication  or  compete  for  subprocessor 
application. 

A3* 2  -  When  paired  with  an  expression-state,  a 
control-point  will  have  associated  with  it  the 
type  of  subprocessor  to  be  applied. 

The  subprocessor  type  associated  with  a  control- 
point  that  is  paired  with  an  expres3lon-state  Informs  the 
systems  processor  which  type  of  subprocessor  is  to  be 
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thus  control  what  kind  of  subprocessor  Is  to  applied  to  a 
particular  expression-state  by  ensuring  that  the  ES/CP 
pair  has  the  correct  subprocessor  type  associated  with  it. 
The  system  processor  could  not  otherwise  determine  which 
subprocessor  to  apply  to  a  particular  ES/CP  pair.   The  sys- 
tem processor  can  therefore  operate  in  a.  purely  reflex  man- 
ner and  not  be  concerned  about  any  potential  ambiguity  in 
the  mapping  of  subprocessor  type  onto  expression-state  type. 

Design  decision  A*i  -  Control-points  will  serve 
as  uniquely  named  destination  addresses  for  inter- 
process messages.   The  arrival  of  such  messages, 
as  well  as  local  subprocessor  operations,  may  des- 
ignate an  ES/CP  pair  as  requesting  a  subprocessor, 
regardless  of  the  status  of  other  pairs.   The  sys- 
tem processor  will  apply  at  most  one  subprocessor 
to  a  process  state  each  process  step. 

If  interprocess  communication  is  to  be  permitted  be- 
tween the  processes  in  the  network,  there  must  be  some  way 
of  unambiguously  directing  each  message  to  the  destination 
process.   Control-points  are  used  to  name  particular  ex- 
pression-states within  the  process  state.   By  using  them 
for  communication  also,  other  processes  are  able  to  direct 
their  messages  to  a  particular  ES/CP  pair  within  a  process 
state,  not  just  to  the  process  Itself.   Addressing  an  inter- 
action to  a  control-point  name  In  effect  addresses  the  pro- 
cess which  contains  an  ES/CP  pair  by  that  name.   Process 
designers  thus  need  not  be  concerned  about  the  residence  of 
the  destination  process  as  far  as  message  delivery  is  con- 
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cerned.   Directing  messages  to  particular  ES/CP  pairs  pro- 
vides a  generality  for-  process  designers  not  normally  avail- 
able. 

If  control-point3  are  uniquely  named  and  messages 
directed  to  particular  ES/CP  pairs  the  system  processor  can 
complete  the  delivery.   If  the  messages  were  directed  only 
to  the  process  then  the  subprocessors  would  have  to  deliver 
them  to  the  appropriate  expression-state.   Constraints  would 
have  to  be  placed  on  all  subprocessor  designers  to  ensure 
they  all  did  it  by  the  same  conventions.   This  would  be  a 
restriction  of  their  design  freedom  which  is  not  necessary 
when  the  system  processor  delivers  messages  to  uniquely 
named  ES/CP  pairs. 

The  system  processor  must  know  when  a  process  is  re- 
questing that  subprocessors  be  applied.  Part  of  the  status 
of  a  control-point  must  then  be  whether  or  not  it  is  making 
such  a  request  (Demand  Status). 

When  a  given  subprocessor  is  interpreting  the  process 
state,  it  would  be  arbitrary  to  prevent  that  subprocessor 
from  changing  the  demand  status  of  the  other  ES/CP  pairs  in 
that  process  state.   Process  designers  should  have  the 
flexibility  to  make  use  of  such  intraprocess  (interexpres- 
slon-state)  control  operations.   This  design  choice  is  con- 
sistent with  our  desire  to  permit  subprocessor  designers  to 
perform  any  operation  which  remains  local  to  a  process 
state,  provided  of  course  it  does  not  violate  any  of  the 
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other  constraints  or  design  decisions. 

Interprocess  messages  could  have  been  received  pas- 
sive] y  in  the  sense  that  each  subprocessor  would  have  had 
to  look  in  a  buffer  to  see  if  there  were  any  pending  mes- 
sages.  Active  designation  of  an  ES/CP  as  demanding  a  sub- 
processor  upon  the  receipt  of  an  interprocess  message  would 
be  analogous  to  Interprocess  interrupts  and  provide  a  much 
more  flexible  control  mechanism. 

At  a  minimum,  some  sort  of  wake-up  signal  has  been 
accepted  as  a  necessary  mechanism  in  most  of  the  systems 
recently  designed.   This  makes  a  wait  loop  unnecessary.   A 
process  may  go  to  sleep  pending  such  signals.   The  wakeup 
mechanism  can  be  considered  a  type  of  message  from  some 
special  system  process.   In  such  designs  the  "system  pro- 
cess" is  a  routine  buried  in  the  operating  system  struc- 
tures.  In  our  design,  the  operating  system  is  not  unique. 
It  would  be  a  set  of  processes,  managed  like  all  other  pro- 
cesses by  process  designers,  whose  most  important  attribute 
is  their  relative  position  in  the  process  hierarchy.   There 
is  no  reason  why  only  a  system  process  should  have  such 
abilities  in  general.   The  active  receipt  of  messages  in 
our  network  design  permits  interprocess  interactions  to  have 
the  same  effect  and  provide  process  management  the  desired 
generality. 

The  introduction  of  message  activated  ES/CP  pairs 
(message  sets  the  pair  demanding)  means  that  more  than  one 
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such  pair  in  each  process  state  could  be  demanding  a  sub- 
processor  at  one  time  (just  as  for  active  hierarchial  in- 
terrupt routines).   If  only  subprocessor  operations  local 
to  a  process  could  have  activated  other  pairs ,  such  opera- 
tions could  have  been  constrained  so  that  the  subprocessor 
made  sure  that  only  one  such  pair  was  requesting  at  a  time. 
To  require  the  same  thing  for  interprocess  messages  would 
require  interacting  with  at  least  one  system  processor.   The 
system  processor  would  have  to  be  greatly  complicated  if  it 
had  to  provide  information  to  a  message  generating  subpro- 
cessor on  what  the  receiving  process  was  doing.   The  trans- 
mitting process  might  experience  long  delays  waiting  for 
necessary  information  if  the  processes  were  in  different 
systems. 

Permitting  more  than  one  ES/CP  pair,  within  a  process 
state,  to  be  requesting  a  subprocessor  greatly  simplifies  the 
design.   The  system  processor  does  not  have  to  provide  ser- 
vices to  a  process  about  what  the  other  process  is  doing 
and  the  generating  subprocessor  does  not  have  to  include 
provisions  for  such  interactions  with  the  system  processor. 
An  incoming  message  may  designate  an  ES/CP  pair  as  demanding 
a  subprocessor  independently  of  the  status  of  other  pairs. 

Multiple  demanding  ES/CP  pairs  within  one  process 
state  introduce  a  potential  ambiguity  into  process  behavior 
which  must  be  removed.   If  the  processes  in  the  network  are 
to  be  well-defined,  both  process  designers  and  the  system 
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processor  must  know  unambiguously  which  one  of  a  set  of  de- 
manding ES/CP  pairs  will  receive  the  subprocessor.   In  order 
to  prevent  subprocessor  race  conditions  for  access  to  parts 
of  a  process  state,  and  still  permit  multiple  subprocessors 
to  access  that  state,  either  disjoint  environments  or  inter- 
subprocessor  race  resolving  would  be  required. 

The  only  reason  to  have  multiple  expression-states 
in  a  single  process  is  to  share  environments.   Requiring 
expression-state  environments  always  to  be  disjoint  is 
equivalent  to  putting  them  in  separate  processes.   The  sys- 
tem processor  might  be  able  to  check  for  disjoint  environ- 
ments within  a  process-state  before  applying  the  subpro- 
cessors.  Even  if  decision  procedures  could  be  determined 
for  some  initial  set  of  subprocessors,  any  additions  to  the 
set  would  require  modifications  to  the  procedures  and  great- 
ly complicate  the  network  design.   We  have  attempted  to 
keep  the  system  processor  simple  and  design  it  in  a  way 
which  permits  the  simple  introduction  of  new  subprocessors. 
Requiring  it  to  determine  disjoint  environments  at  subpro- 
cessor allocation  time  is  a  complication  not  necessary  if 
the  system  processor  applies  only  one  subprocessor  to  the 
process  state  each  process  step. 

Subprocessors  cannot  take  care  of  this  problem  them- 
selves because  it  would  require  inter-subprocessor  inter- 
actions which  would  violate  the  basic  independence  of  sub- 
processors.   We  introduced  subprocessors  so  they  could  be 
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independently  designed  v\rith  no  concern  for*  what  other  sub- 
processors  are  doing.   Each  subprocessor  designer  knows  that 
no  other  subprocessor  can  access  the  process  state  until  it 
has  completed  its  operation.   A  process  will  undergo  a  pro- 
cess step  each  time  a  subprocessor  is  applied  to  its  process 
state. 

The  system  processor  and  process  designers  must  not 
encounter  any  ambiguities  concerning  which  subprocessor  will 
be  applied  to  a  process  state  containing  more  than  one  de- 
manding ES/CP  pair.   Therefore,  there  must  be  a  well-defined 
decision  procedure  which  both  the  system  processor  and  pro- 
cess designer  can  use  to  make  such  a  determination. 

It  would  be  arbitrary  for  this  design  to  say  which 
such  procedure  must  be  used.   Preemptive  (priority)  or  non- 
preemptive  alternatives  are  possible.   In  the  case  of  non- 
preemptive,  once  an  ES/CP  pair  had  a  subprocessor  applied 
to  it,  it  would  continue  having  it  applied  until  it  had 
completed  its  operations.   In  the  case  of  the  priority 
hierarchy  (preemptive),  a  higher  priority  ES/CP  pair  might 
become  demanding  before  the  lower  priority  pair  had  com- 
pleted.  In  this  case,  the  system  processor  would  cease 
applying  a  subprocessor  to  the  lower  priority  pair  (at  the 
end  of  that  process  step)  and  start  applying  one  to  the 
higher  priority  pair.   Such  a  modification  of  subprocessor 
application  before  an  ES/CP  pair  has  completed  its  sequence 
of  process  steps  will  be  defined  as  an  interrupt  within  the 
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network  structures. 

Faults ,011  the  other  hand,  will  be  defined  as  occur- 
ring while  a  subprocessor  Is  carrying  out  a  process  step,  re- 
sulting in  a  change  in  the  sequence  in  which  the  subprocessor 
is  interpreting  the  current  program  stream.   During  the  exe- 
cution of  a  subprocessor,  certain  abnormal  conditions  may 
occur  which  normally  require  the  subprocessor  to  change  the 
sequence  of  transformations  it  is  carrying  out.   The  actual 
mechanism  used  must,  of  course,  be  language  dependent  and 
therefore  part  of  the  design  of  that  subprocessor.   Faults 
are  always  handled  as  operations  local  to  the  expression- 
state  which  was  being  interpreted  when  the  fault  occurred. 

A*i.l  -  Each  process  state,  except  the  PR  Pro- 
cess state,  will  contain  an  ES/CP  pair  which 
can  interrupt  all  others  In  that  process  and 
which  can  be  interpreted  by  the  AO  subproces- 
sor. 

We  have  delegated  to  the  AO  subprocessor  designer 
the  responsibility  for  fulfilling  the  network  responsibili- 
ties for  accountable  objects.   It  is  of  utmost  importance 
that  it  not  be  possible  for  any  process  to  prevent  the  AO 
subprocessor  from  carrying  out  its  duties. 

Any  process  must  be  capable  of  accepting  at  least 
one  control-point  in  order  to  accomplish  any  transformations 
on  the  process  state.   Each  process  state  will  thus  contain 
at  least  one  accountable  object  (that  CP)  which  the  AO  sub- 
processor  must  protect  and  account  for.   The  AO  designer 
must  be  permitted  to  maintain  whatever  information  is 
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necessary  for  the  AC)  subprocessor  to  do  its  job,  Irrespective 
of  what  else  the  process  may  be  doing.   Each  process  sta.te 
must  therefore  contain  an  expression-state  where  such  in- 
formation is  maintained  and  available  to  the  AO  subprocessorc 
In  order  for  the  AO  subprocessor  to  be  applied,  the  expres- 
sion-state must  be  paired  with  a  control-point.   Each  pro- 
cess state  must  therefore  always  have  an  ES/CP  pair  to  which 
the  AO  subprocessor  can  be  applied. 

A  process  must  never  prevent  the  AO  subprocessor  from 
being  applied  when  the  ES/CP  pair  is  demanding  the  AO  sub- 
processor.   Since  the  system  processor  applies  subprocessors 
to  process  states ,  according  to  some  well-defined  algorithm, 
the  design  must  constrain  the  algorithm  by  which  this  is 
done.   The  AO  subprocessor  must  be  applied  when  demanded, 
in  spite  of  what  other  requests  for  subprocessor  application 
are  outstanding  within  a  process  state.   The  AO  subprocessor 
ES/CP  pair  must  therefore  interrupt  all  other-  subprocessors. 
This  is  the  only  way  the  necessary  guarantee  (that  the  pro- 
cess cannot  lock  out  the  AO  subprocessor)  can  be  made  to  the 
designer  of  the  AO  subprocessor. 

A*j.2  -  In  addition  to  its  basic  functions,  the 
A~0  subprocessor  will  be  responsible  for  regu- 
lating process  birth,  death,  and  intersystem 

movement. 

Because  of  possible  effects  on  accountable  objects, 
the  design  must  (decision  Al )  delegate  to  the  AO  subproces- 
sor designer  the  responsibility  for  validating  process  birth, 
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death,  and  intersystem  movement.   For  example,  a  process 
must  not  be  permitted  to  commit  suicide  and  destroy  some 
delegated  accountable  objects.   Birth  arid  intersystem  move- 
ment of  processes  may  also  effect  the  accountable  objects 
for  which  the  AO  subprocessor  is  responsible.   The  AO  sub- 
processor  designer  must  be  able  to  prevent  all  such  problems, 

The  network  design  cannot  permit  arbitrary  subpro- 
cessors  to  fulfill  these  responsibilities  since  this  would 
require  interference  with  their  design  (Al)  to  obtain  appro- 
priate guarantees.   The  design  therefore  must  not  permit 
them  to  perform  process  birth,  death,  or-  intersystem  move- 
ment.  By  requiring  the  requests  for  these  operations  to  be 
forwarded  to  the  AO  subprocessor,  the  AO  designer  can  con- 
trol what  will  be  permitted  and  what  will  not.   The  network 
design  thus  fulfills  its  responsibilities  with  respect  to 
accountable  objects,  and  to  the  AO  subprocessor  designer. 

Communication 

Design  decision  A5   -  A  process  may  generate  a 
single  interprocess  message  each  process  step, 
which  is  broadcast  by  the  system  processor  to 
a  particular  buffer  associated  with  the  destina- 
tion control-point.   Process  designers  can  control 
the  right  to  transmit,  the  right  to  listen,  and 
the  right  to  allow  an  ES/CP  pair  to  become  de- 
manding as  a  result  of  a  buffered  message. 

Process  designers  must  decide  what  message  to  gener- 
ate and  the  information  necessary  to  generate  the  message 
must  come  from  within  the  process  state.   Since  message 
generation  is  therefore  a  local  operation  on  a  process 
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state,  responsibility  for  it  can  be  delegated  to  the  sub- 
processors.   The  transmission  and  delivery  of  that  message 
are  not  operations  local  to  one  process  state  and  therefore 
must  be  performed  by  the  Involved  system  processors.   Al- 
though the  design  of  subprocessors  has  been  delegated,  the 
design  of  the  system  processor  has  not.   Several  constraints 
must  therefore  be  placed  on  the  design  of  message  genera- 
tion so  that  the  system  processor  design  can  be  completed. 

A  subprocessor  may  generate  only  a  single  message 
each  process  step.   This  choice  was  made  primarily  for  sim- 
plicity and  because  it  does  not  really  restrict  a  process 
designer  since  the  process  can  r<  petitively  generate  a  new 
message  on  each  process  step.   The  design  of  the  system 
processor  is  simplified  since  it  does  not  need  the  additional 
operators  required  to  dispatch  multiple  messages  from  each 
process.   In  addition,  although  a  subprocessor  may  hit  a 
bound  during  the  generation  of  a  message  because  of  the 
size  of  the  message,  after  it  is  generated  the  system  pro- 
cessor sees  only  a  single  bounded  message.   The  complexity 
of  a  message  is  subprocessor  dependent.   Although  a  sub- 
processor  may  require  multiple  process  steps  to  construct 
a  message,  the  system  processor  need  not  be  concerned  with 
such  problems. 

After  generation  by  a  subprocessor,  the  messages  are 
"broadcast"  by  the  system  processor  to  a  particular  buffer 
associated  with  the  destination  control-point.   "Broadcast" 
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means  that  the  system  processor  will  transmit  the  message 
immediately.   There  will  be  no  intersystem  synchronization 
to  determine  if  the  destination  process  is  not  listening, 
or  already  has  a  message  in  that  buffer.   The  destination 
CF  might  not  even  be  a  member  of  some  ES/CP  pair  which  would 
result  in  the  network  ignoring  the  message. 

These  types  of  interactions  due  to  interprocess  mes- 
sage handDing  are  the  responsibility  of  process  designers, 
not  the  system  processor.   When  a  process  says  transmit, 
the  system  processor  may  not  knew  enough  about  the  reasons 
for  the  request  to  say  such  a  command  is  correct  or  not. 
Only  a  process  designer  can  know.   For  example,  there  may 
be  processes  which  wish  to  overwrite  an  old  message  if  it 
has  not  already  been  interpreted  by  the  destination  process 
(e.g.,  a  real  time  clock  interrupt).   Since  there  is  no  def- 
inition of  the  relative  speeds  of  systems  in  the  network, 
nothing  can  be  said  about  how  soon  (number  of  process 
steps)  the  message  will  be  delivered  if  the  receiving 
process  is  in  another  system. 

If  process  designers  are  to  be  able  to  control  the 
use  of  a  flexible  interprocess  communication  mechanism,  they 
must  be  able  to  control  the  right  to  transmit  to  a  particu- 
lar buffer  associated  with  the  destination  control-point. 
Although  a  single  receiving  buffer  could  have  been  asso- 
ciated with  each  control-point,  this  would  have  been  un- 
necessarily constraining  on  process  designers.   Two  pro- 
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cesses  in  different  systems,  interacting  with  a  third,  would 
have  to  interact  themselves  to  ensure  that  only  one  of  them 
at  a  time  was  using  the  buffer.   If  only  a  single  buffer  for 
each  ES/CP  pair  was  allowed,  the  receiving  process,  of  course, 
could  provide  as  many  ES/CP  pairs  as  necessary  to  receive 
messages  from  different  processes,  but  this  seems  like  an 
unnecessary  waste  of  control-points.   Multiple  buffers 
(which  need  not  be  created  unless  desired)  provide  a  more 
flexible  interprocess  interaction  capability  without  sig- 
nificant complication. 

Each  buffer  can  be  thought  of  as  a  queue  capable  of 
containing  one  or  more  messages.   The  most  degenerate  queue 
is  of  size  one  and  is  the  simpllst  from  a  design  point  of 
view,  but  larger  buffer  queue  sizes  might  be  useful  for  cer- 
tain kinds  of  applications.   At  this  point  in  the  design  it 
would  be  arbitrary  to  say  what  the  queue  length  must  be. 
If  a  logically  infinite  queue  is  considered,  then 
the  design  must  consider  the  fact  that  the  implementation 
might  actually  have  a  fixed  number  of  buffers  to  use.   This 
is  just  the  boundedness  problem  and  therefore  must  be  con- 
sidered anyway.   If  the  queue  length  is  logically  finite 
then  the  design  must  consider  what  to  do  in  the  case  of 
queue  overflow.   For  example,  the  newest  message  would  force 
the  oldest  message  to  be  lost.   This  is  what  is  done  in  the 
case  of  length  one  (e.g.,  message  overwrite).   Message  re- 
ceipt resolution  in  a  digital  system  can  be  no  better  than 


106 
the  system  cycle.   It  will  be  pointed  out  later  that  a  pro- 
cess step  in  this  design  occurs  only  once  every  three  system 
cycles.   The  queue  greater  than  one  would  permit  the  system 
to  resolve  messages  each  system  cycle  instead  of  once  each 
process  step.   In  this  design  a  queue  of  three  would  give 
the  system  cycle  message  resolution  if  the  process  cleared 
the  queue  each  process  step. 

The  design  requires  a  source  to  direct  messages  to 
particular  control-point  buffers.   Process  designers  can 
then  be  provided  mechanisms  for  controlling  Interprocess 
interactions  due-  to  competition  for  buffers  by  providing 
control  over  the  right  to  transmit  to  particular  buffers. 
Single  or  multiple  rights  could  be  provided  (such  rights 
will  be  accountable  objects  managed  by  process  designers). 
Multiple  rights  to  transmit  to  a  single  buffer  might  result 
in  race  conditions.   The  resolution  of  such  conflicts  between 
asynchronous  systems  would  require  a  significant  complication 
of  the  system  processors.   Therefore,  the  use  of  multiple 
rights  to  transmit  to  one  buffer  must  be  cooperative  and 
either  Involve  only  identical  messages  (an  interrupt)  or  be 
used  by  only  one  process  at  a  time. 

The  design  will  also  provide  process  designers  with 
the  ability  to  control  when  a  process  will  listen  (buffer  a 
message)  and  when  the  ES/CP  will  demand  a  subprocessor  to 
take  care  of  buffered  messages.   Although  control  of  trans- 
mission is  sufficient  to  accomplish  this,  local  control  of 
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message  buffering  by  the  receiving  process  makes  the  process 
designer's  job  simpler.   Since  the  buffers  associated  witn  a 
control-point  are  contained  in  the  system  containing  the 
destination  control-point,  informing  a  system  processor  to 
listen  or  not  is  simple.   Controlling  the  rights  to  transmit 
would  present  processes  a  much  more  difficult  task.   For  ex- 
ample, a  process  might  become  uncooperative  and  start  trans- 
mitting arbitrary  messages  to  all  buffers  to  which  it  has  a 
right  to  transmit.   It  may  take  numerous  process  steps  be- 
fore its  parent  can  be  notified,  and  can  discipline  the 
child.   Control  over  listening  solves  this  problem  easily. 

Each  control-point  buffer  records  one  complete  in- 
corning  message.   Process  designers  in  addition  to  control- 
ling the  listening  of  each  buffer,  will  be  able  to  control 
when  such  buffered  messages  will  cause  the  ES/CP  pair  to 
demand  a  subprocessor  to  process  such  messages.   They  are 
the  only  agents  who  know  enough  about  the  design  of  their 
processes  to  safely  do  this. 

Foreign  systems  were  introduced  as  a  result  of  con- 
straint Al  to  provide  an  open  network.   Since  nothing  is 
assumed  to  be  known  by  the  network  designers  about  foreign 
systems  or  their  processes,  foreign  systems  must  not  be 
permitted  to  violate  any  of  the  network  constraints  or  de- 
sign decisions.   Thus,  the  only  interactions  which  can  be 
permitted  by  foreign  systems  with  the  network  will  be  the 
exchange  of  messages  with  processes  in  the  network. 
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Such  communication  will  look  no  different  than  any 
normal  interprocess  communication.   A  control-point  capable 
of  serving  as  a  destination  for  messages  from  foreign  sys- 
tems will  have  a  single  buffer  associated  for  each  such 
source.   Process  management  will  have  all  of  the  mechanisms 
discussed  above  for  controlling  the  receipt  of  such  messages. 
Transmission  to  foreign  systems  will  be  represented  only  a 
a  collection  of  rights  to  transmit  to  some  destination  "con- 
trol-points" which  do  not  exist  in  the  network. 

Process  designers  will  be  responsible  for  controlling 
interactions  with  such  systems  including  the  interpretation 
of  such  messages  and  other  related  matters.   The  network  de- 
sign thus  fulfills  its  responsibilities  by  constraining  the 
interactions  between  foreign  systems  and  the  network  sys- 
tems to  occur  only  using  normal  interprocess  communication 
mechanisms.   By  constraining  such  interactions  to  occur  only 
with  the  processes  in  the  network,  and  not  the  systems  them- 
selves, process  designers  can  be  held  responsible  for  the 
management  of  such  interactions. 

A  basic  description  of  the  operation  of  the  system 
processor  can  now  be  given.  Each  system  processor  is  de- 
fined as  having  a  major  cycle  consisting  of  three  phases. 
A  process  may  undergo  one  process  step  each  major  cycle. 
The  requirement  for  phases  is  a  direct  consequence  of  the 
fact  that  the  system  processor  must  perform  all  of  the  oper- 
ations not  local  to  a  process  state  without  race  conditions. 
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Some  of  these  operations  are  sequential  in  nature.   During 
the  first  phase  (subprocessor  allocation  determination)  the 
system  processor  determines  if  any  buffered  messages  should 
cause  an  ES/CP .pair  to  request  a  subprocessor.   Using  this 
information  and  information  about  all  other  requesting  pairs, 
it  determines  v/hich  ES/CP  pair  within  each  process  state 
should  have  the  subprocessor  applied,  and  delivers  messages 
to  that  control-point  if  that  is  appropriate.   The  second 
phase  is  subprocessor  application.   During  this  phase  sub- 
processors  dispose  of  messages  and  carry  out  other  operations 
on  the  process  state.   These  subprocessor  transformations 
will  constitute  that  process  step.   The  final  phase  is  mes- 
sage dispatching.   Any  messages  which  vie  re  generated  by  the 
subprocessors  during  the  process  step  are  dispatched  by  the 
system  processor  and  the  next  cycle  begins. 

Definition »  Modification,  and  Bounds 

Design  decision  A6  -  The  initial  network  def- 
inition will  consist  of  one  basic  system  with 
an  initial  root  process  state.  Network  modi- 
fication operators  will  permit  the  creation  of 
at  least  additional  basic  systems,  subproces- 
sors, subprocessor  operators,  and  system  pro- 
cessor operators  for  control-point  housekeeping. 

Network  modification  was  introduced  in  the  previous 
chapter  (C5)  and  the  network  designers  were  delegated  re- 
sponsibility for  definition  of  the  initial  network  and  all 
potential  evolutionary  paths.   Without  evolution,  a  particu- 
lar network  definition  would  have  to  be  chosen  which  might 
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handicap  some  potential  applications  of  the  network  design,, 
A  minimum  network,  with  evolution,  permits  each  application 
to  evolve  the  network  definition  to  fulfill  its  own  needs 
(within  the  constraints  placed  on  evolution  by  the  network 
designers).   This  design  tries,  wherever  possible,  to  dele- 
gate to  the  users,  authority  and  responsibility  for  those 
decisions  best  made  in  the  context  of  their  applications. 

All  basic  systems  will  consist  of  a  system  processor 
itaining  the  three  required  subprocessors  and  a  PR  process 
state.   In  addition,  the  initial  basic  system  must  also  con- 
tain a  root  process  state  which  serves  as  the  initial  root 
of  the  process  tree,  defines  an  initial  set  of  accountable 
objects,  and  by  repeatedly  executing  or  delegating  modifica- 
tion operators,  generates  the  particular  network  definition 
desired. 

The  set  of  network  modification  operators,  operate 
on  the  definition  itself  and  not  on  the  process  states.   They 
are  meta  operators  and  either  act  as  a  no-op  if  the  request 
is  for  a  permissible  path  of  evolution  or  fault  if  it  is 
not  (N4).   Such  evolution,  other  than  the  addition  of  a  new 
system,  must  be  local  to  the  system  within  which  the  opera- 
tor was  executed  (M5),  and  process  designers  must  be  able  to 
limit  the  effects  of  a  such  operations  to  the  process  exe- 
cuting them  (N6) . 

A (5.1  -  The  design  of  modification  operators 
will  be  delegated  to  subprocessor  designers. 
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Modification  operators  will  not  introduce 
new  modification  operators. 

Along  with  the  initial  network  definition,  the  net- 
.work  designer  is  responsible  for  all  evolutionary  paths,  but 
process  designers  are  responsible  for  selecting  which  evolu- 
tionary paths  to  follow  (D6).   Modification  operators  there- 
fore must  be  available  to  the  root  process,  in  the  initial 
languages  provided,  if  it  is  to  be  able  to  create  the  desired 
networks.   Since  language  design  has  been  delegated  to  sub- 
processor  designers,  the  design  of  the  modification  opera- 
tor themselves,  must  also  be  delegated  to  the  subprocessor 
designer. 

The  problem  of  proving  that  a  modification  operator 
does  not  permit  a  violation  of  any  of  the  constraints  or 
design,  decisions  is  greatly  simplified  if  we  do  not  permit 
a  modification  operator  to  introduce  another  modification 
operator.   Such  operators  would  require  recursive  proofs 
which  seem  to  be  impractical.   The  design  of  the  original 
operators  seems  to  present  sufficient  challenge  for  the  pre- 
sent. 

Design  decision  A7  -  Inaccessible  objects  may 
result  from  met a-operat ions  invoked  by  imple- 
mentation designers  because  either  a  subpro- 
cessor hits  a  bound  or  there  is  an  implementa- 
tion failure.   Subprocessors  trying  to  access 
an  inaccessible  object  will  fault. 

The  network  design  is  to  include  bounded  computer 
systems  (PI).   Problems  due  to  having  limited  physical  re- 
sources which  the  implementation  cannot  solve  and  which 
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affects  a  process  state  in  the  network,  must  be  reflected  in 
the  process  state  structure  so  process  designers  may  amelior- 
ate the  consequences  (D'J). 

Implementation  failures  are  a  special  case  of  the 
boundedness  problem.   Given  any  implementation,  there  is  some 
probability  it  will  fail,  the  particular  probability  being  a 
function  primarily  of  the  finite  physical  implementation. 
By  increasing  the  assets  available,  implementation  design- 
ers could  reduce  the  probability  of  such  failures.   In  the 
limit,  such  failures  could  be  eliminated,  but  since  no  im- 
plementation will  have  unlimited  resources,  provision  for 
implementation  failures  must  be  included  as  part  of  the 
boundedness  problem. 

Inaccessible  Objects  are  a  sufficient  solution  to 
the  problems  of  implementation  failures.   When  the  implementa- 
tion recognizes  a  problem  which  it  cannot  solve,  it  will 
identify  the  smallest  logical  unit  of  the  process  state 
which  contains  the  damage  (this  might  be  the  value  of  a  var- 
iable or  the  whole  process  state  itself).   The  implementation 
will  then  mark  this  smallest  unit  as  an  inaccessible  object 
and  continue  until  such  time  as  a  subprocessor  attempts  to 
access  that  part,  of  the  process  state.   The  subprocessor  will 
be  caused  to  fault  when  it  attempts  to  access  an  inaccessible 
object.   This  mechanism  is  sufficient  since  it  does  accom- 
plish notification  of  damage  to  a  process  potentially  capa- 
ble of  doing  something  to  ameliorate  the  problem.   If  no 
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process  ever  tries  to  access  the  information  then  no  notifi- 
cation occurs. 

If  the  design  required  the  implementation  to  notify 
some  process  when  an  inaccessible  object  occurred,  some  de- 
termination would  have  to  be  made  of  which  process  to  notify, 
how,  and  when.   This  probably  cannot  be  properly  decided  by 
implementation  designers  since  they  do  not  know  enough  about 
what  process  designers  were  trying  to  accomplish. 

Creating  inaccessible  objects  within  a  process  state 
must  be  a  met a  operation  to  the  defined  network  since  the 
decision  of  when  and  how  to  do  it  must  be  delegated  to  the 
implementation  designers.   It  is  met a  in  the  sense  that  the 
creation  of  the  inaccessible  objects  is  not  formally  defined 
as  an  operator  in  the  network  definition.   The  processes 
cannot  execute  an  operation  and  create  one,  they  are  created 
only  by  the  implementation.   Subprocessor  designers  must  de- 
fine what  their  subprocessors  will  do  upon  receiving  a  fault 
saying  it  has  attempted  to  access  an  inaccessible  object. 

There  is  nothing  in  the  design  which  v^ould  prohibit 
some  type  of  "meta  deal"  between  subprocessor  designers  and 
implementation  designers  so  that  an  elastic  bound  fault  will 
occur  instead  of  creating  an  inaccessible  object  in  some 
cases.   The  operands  to  an  operation  might  not  be  destroyed 
until  the  implementation  is  sure  the  operation  can  complete. 
This  would  permit  the  implementation  to  return  things  to  the 
way  they  were  at  the  beginning  of  the  operation  and  return  a 


fault  to  the  subprocessor  saying  the  operation  would  have 
resulted  in  an  "inaccessible  object"  if  completed.   Process 
designers  might  then  be  able  to  take  care  of  the  problem. 

Although  the  root  process  contains  an  initial  set  of 
accountable  objects,  as  the  network  evolves  this  set  may  net 
be  sufficient.   For  example,  as  the  network  definition  is 
modified  to  permit  the  system  processor  to  take  care  of  addi- 
tional control  points,  process  management  will  want  to  intro- 
duce into  the  process  states  new  accountable  objects  repre- 
senting those  additional  control  points.   Since  the  modifi- 
cation operators  are  no-ops  and  do  not  modify  the  process 
states,  an  additional  operator  must  exist  to  introduce  the 
necessary  accountable  objects.   The  designer  cf  the  AO  sub- 
processor  chooses  particular  representations  for  accountable 
objects  and  therefore  must  define  the  operations  which  intro- 
duce new  accountable  objects,  although  some  of  the  operators 
could  be  delegated  to  other  subprocessor  designers  under 
Bl.   Heta  arrangements  with  the  implementer  which  define 
mappings  between  accountable  objects  and  particular  opera- 
tors in  the  system  processor  structure  is  also  the  AO  de- 
signers responsibility.   These  are  not  modification  operators 
since  they  operate. on  the  process  state  and  not  on  the  system 
processor  definition. 


A7 . 1  -  Implementation  failures  affecting  the 
accountable  object  chain  may  cause  ghost  pro- 
cesses. 
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If  damage  occurs  only  to  accountable  objects,  a  suf- 
ficient solution  is  to  handle  it  using  the  inaccessible  ob- 
ject mechanism.   Host  likely,  the  designer  of  the  AO  subpro- 
cessor  will  invoke  another  meta  arrangement  with  the  imple- 
mentation which  will  permit  the  implementers  to  notify  the 
AO  ES/CP  of  such  damaged  accountable  objects.   The  AO  sub- 
processor  can  then  be  invoked  to  provide  some  services  to 
the  process  to  help  it  solve  the  problem.   Such  operations 
are  not  necessary  and,  as  part  of  the  AO  subprocessor  design, 
they  are  not  of  interest  here. 

When  part  of  the  accountability  chain  is  destroyed 
but  some  of  the  accountable  objects  are  not  damaged,  that 
part  of  the  chain  relevant  to  those  objects  can  be  recon- 
structed through  ghost  processes.   A  ghost  process  is  an  in- 
accessible object,  except  for  the  AO  type  ES/OP  pair  which 
contains  a  reconstructed  accountability  chain.   It  is  up  to 
the  implementation  designers  to  do  the  best  they  can  to  put 
the  chain  back  together  by  providing  the  appropriate  informa- 
tion to  the  AO  subprocessor.   Since  there  is  a  unique  name 
for  all  processes  (tree  of  process  names),  such  reconstruc- 
tion of  the  chain  is  possible  as  long  as  the  accountable 
object  themselves  exist.   The  design  choice  here  is  to  re- 
quire the  implementers  to  do  the  reconstruction  wherever 
possible. 

Some  of  the  subprocessor  designers  may  wish  to  pro- 
vide some  services  to  permit  the  processes  to  be  notified  of 
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problems  with  the  accountable  object  chain,  but  again,  this 
is  not  necessary.   Since  processes  may  exist  in  different 
systems,  the  mechanism  as  presented  here  would  still  be 
necessary  since  the  system  containing  a  damaged  process 
state  might  undergo  several  process  steps  before  the  noti- 
fied process  is  able  to  act. 


Initial  System  Choices 


This  chapter  has  informally  presented  the  essential 
network  features  of  the  design.   The  constraints  and  design 
decisions  define  the  members  of  the  set  of  networks  that  are 
of  interest,,   Specific  selections  must  now  be  made  to  define 
the  initial  network  system  from  which  the  desired  networks 
within  the  set  may  evolve.   Although  all  networks  within  the 
set  are  potentially  reachable,  any  particular  design  might 
limit  those  reachable  by  providing  an  appropriate  selection 
of  modification  operators.   Since  the  definition  of  modifi- 
cation operators  has  been  delegated  to  the  subprocessor  de- 
signers, little  more  will  be  said  about  which  evolutionary 
paths  will  be  available  in  any  particular  network. 

The  initial  system  will  not  be  highly  evolved  and 
therefore  will  provide  maximum  potential  for  evolution. 
This  is  good  because  it  encourages  the  subprocessor  designers 
to  include  the  general  meta  modification  operators  which  can 
create  those  specific  features  which  might  be  desirable. 
Below  is  a  list  of  the  structures  to  be  included  in  the 
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Initial  network  definition  and  following  it  will  be  a  de- 
scription of  some  of  the  reasons  for  those  particular  choices. 

Initial  System  Processor 

A.  Service  functions  -  not  local  to  a  process, 
Subprocessor  application  by  priority. 
Message  dispatching  and  delivery. 
Message  buffering. 

Start  process. 
Modification  invocations. 

B.  Subprocessors. 
Type  -  AOj  GP,  PR. 

Co   Process  states. 

(1)  Types 

PR  process  state. 

PR  type  control-point  and  expression- 
state. 
Initial  root  process  state. 

AO  and  GP  type  expression-3tate. 

AO  and  GP  type  control-point. 

(2)  Control-points 
Subprocessor  type  static. 
Priority  static. 

PR  -  one  priority. 

AO  -  highest. 

GP  -  each  unique. 
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Demand  bit. 

Buffers,  each  with  an  arm  bit. 

PR  -  1  for  each  network  system. 
1  acknowledge 
1  for  each  process  In  that  system 

AC  -  3  +  N,  Interface,  acknowledge, 
parent,  +  1   for  each  child 

BP  -  fixed  number  -  (initial  1). 

Enable  bit 

Deliver  order  bit 

The  initial  network  definition  consists  of  one  sys- 
tem processor  (containing  the  AO,  GP,  and  PR  subprocessors ) 
along  with  a  PR  process  state  and  an  initial  root  process 
state  (A7).   A  priority  hierarchy  of  control-points  has  been 
chosen  as  the  method  by  which  the  initial  system  processor 
will  determine  which  subprocessors  to  apply  to  a  process 
state  with  more  than  one  demanding  ES/CP  pair.   Within  the 
system,  all  requesting  processes  will  receive  a  subprocessor 
in  parallel  each  process  step.   The  priority  mechanism  was 
chosen  because  it  is  simple,  unambiguous,  and  provides  an 
interrupt  capability.   If  our  choosing  this  particular  al- 
gorithm becomes  a  serious  constraint  on  the  introduction  of 
others  because  of  the  set  of  modification  operators  provided, 
it  is  a  constraint  which  can  be  tolerated  because  it  al- 
ready provides  a  greater  generality  than  do  most  current 
designs. 
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In  addition  to  subprocessor  application,  there  are 
several  other  services  which  the  system  processor  will  per- 
form.  Subprocessors  generate  messages,  but  must  leave  them 
for  the  system  processor  to  dispatch  (an  operation  not  local 
to  that  process).   The  same  is  true  of  message  delivery. 
Operators  must  therefore  exist  in  the  system  processor  to 
perform  these  operations  and  to  do  the  housekeeping  for  the 
buffers  associated  with  control-points. 

The  AO  subprocessor  will  indicate  a  process  state 
which  is  validly  requesting  transmission  to  another  system 
and  designate  the  system  to  whlch.it  is  to  be  sent.   The 
system  processor  will  then  deliver  the  marked  process  state 
to  the  local  PR  process  for  transmission  to  the  destination 
system.   The  PR  process  will  then  transmit  that  process 
state  to  the  appropriate  destination  PR  control-point  buffer. 
The  destination  PR  process  will  acknowledge  receiving  either 
the  process  state  or  an  inaccessible  object,  prepare  the 
state  just  received  to  run  in  the  new  system,  if  appropriate, 
and  present  it  to  the  system  processor  to  start.   Since 
starting  a  process  is  not  local  to  the  PR  process  state,  it 
must  be  performed  by  the  system  processor. 

One  last  service  to  be  provided  by  the  system  proces- 
sor has  to  do  with  modification  operators.   Subprocessors 
will  place  in  the  interface  buffers  valid  modification  com- 
mands.  The  system  processor  will  execute  operators  to  clear 
the  buffer  during  the  message  dispatching  phase.   The  system 
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processor  will  undergo  modification  at  the  end  of  the  mes- 
sage dispatching  phase  (after  all  operators  have  completed) 
so  that  at  the  beginning  of  the  message  delivery  phase  the 
new  system  definition  will  be  in  effect.   This  provides  a 
well-defined  place  in  the  operation  of  each  system  processor 
where  the  definition  change  occurs. 

The  PR  process  state  will  contain  only  PR  type  ex- 
pression-states while  the  initial  root  process  will  contain 
both  AC)  and  GP  type  expression-states.  Control-points  will 
be  one  of  the  types  PR,  AO,  and  GP,  and  all  ES/CP  pairs  will 
pair  control-points  and  expression-states  of  the  same  type. 
In  the  initial  definition  there  is  no  need  for  more  compli- 
cated pairings. 

There  will  be  a  fixed  number  of  control-points  in 
the  network  and  additions  to  this  set  will  occur  only 
through  network  modification. 

A  more  dynamic  generation  of  control-point  names  by 
the  system  processor  as  part  of  its  auxiliary  functions 
would  have  been  possible  (instead  of  requiring  modification) 
but  this  would  have  unnecessarily  complicated  the  message 
handling  and  subprocessor  application  operations.   The  trade 
off  required  for  a  non-fixed  number  of  control-points  is 
added  system  processor  cycles.   Iteration  is  required  for 
message  updating  and  subprocessor  application  Instead  of 
the  parallel  operator  application  which  is  possible  when  the 
number  Is  fixed. 
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Each  control-point  will  be  permanently  associated 
with  one  subprocessor  type  (GP,  A0S  PR)  and  will  have  a 
static  position  in  the  priority  hierarchy.   The  static  bind- 
ing of  subprocessor  type  and  priority  to  control-point  name 
simplifies  the  design  of  subprocessor  application  operators 
for  the  initial  network  definition.   These  items  become  part 
of  the  control-point  name  thus  simplifying  representations. 

A  priority  will  be  associated  with  all  control-points. 
PR  control-points  do  not  compete  with  other  control-points 
for  subprocessors.   The  AO  control-points  will  have  higher 
priority  than  all  other  control-points  in  a  process  so  that 
they  will  interrupt  all  other  ES/CP  pairs  in  that  process 
(A6).   All  AO  types  may  share  the  same  priority  since  there 
will  only  be  one  such  control-point  competing  in  each  pro- 
cess state. 

Each  GP  type  control-point  will  be  assigned  a  unique 
priority.   The  initial  network  system  will  contain  only  one 
GP  type  control-point  and  modification  operators  will  be 
used  to  generate  the  desired  number  of  additional  GP  type 
control-points.   An  evolved  network  with  multiple  GP  control- 
points  j  each  with  a  unique  priority,  will  permit  multiple 
GP  type  ES/CP  pairs,  having  interrupt  capabilities,  to  be 
contained  in  one  process  state. 

A  demand  bit  will  be  associated  with  each  control- 
point,  when  it  is  a  member  of  an  ES/CP  pair,  to  indicate 
that  it  is  demanding  a  subprocessor.   An  arm  bit  will  be 
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associated  with  each  control-point  buffer  to  indicate 
whether  or  not  the  system  processor  should  accept  a  mes- 
sage destined  for  that  buffer.   All  buffers  will  have  a 
queue  length  of  one  for  simplicity.   The  PR  control-point 
will  initially  have  one  buffer  for  the  initial  root  process 
and  ons  message  acknowledgment  buffer.   An  additional  buf- 
fer will  be  added  each  time  a  new  system  is  added  to  the 
network  definition  or  a  new  process  is  started  in  that 
system  (and  deleted  when  that  process  is  killed  or  moved). 
This  will  permit  maximum  freedom  of  movement  of  the  processes 
over  the  systems  in  the  network.   PR  control-point  buffers 
are  always  armed. 

The  AO  control-point  will  have  an  interface  buffer, 
an  acknowledgment  buffer,  a  buffer  for  the  parent  process, 
and  one  buffer  for  each  child  with  which  the  AO  subproces- 
sor  can  conduct  its  interprocess  business.   An  Interface 
buffer  is  required  for  each  process,  to  be  used  by  the  sys- 
tem processor,  for  message  dispatching  and  delivery.   Only 
one  Is  necessary  since  the  design  ensures  that  the  system 
processor  will  only  operate  on  it  when  no  subprocessor  is 
being  applied,  and  at  most  one  message  is  generated  by  that 
process  in  a  single  process  step.   Since  an  AO  control-point 
exists  in  each  process,  the  interface  buffer  can  be  associ- 
ated with  it.   The  network  design  puts  no  limit  on  the  num- 
ber of  children  a  process  may  have,  and  they  will  each  have 
an  AO  type  control-point  which  will  need  to  talk  to  their 
parent.   One  buffer  is  also  needed  to  receive  messages  from 
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the  parent.   Such  a  mechanism  is  necessary  to  ensure  that 
no  accountable  object  will  be  lost  because  of  race  con- 
ditions for  a  single  buffer.   AO  control-points  are  always 
armed. 

In  the  case  of  both  PR  and  AO  control-points  there 
will  always  be  at  least  one  buffer  which  will  be  coopera- 
tively used  to  receive  acknowledgments.   One  buffer  is  suf- 
ficient as  long  as  they  transmit  only  one  message  at  a 
time  and  wait  for  the  acknowledged  receipt  of  that  message. 
If,  due  to  operational  requirements,  it  is  desirable  to 
have  more  than  one  message  in  transit  at  a  time,  then  modif- 
ication operators  can  be  executed  to  create  the  desired 
number  of  additional  acknowledgment  buffers. 

Each  GP  control-point  will  have  a  fixed  number  of 
buffers,  not  necessarily  the  same  for  all  control-points. 
The  Initial  definition  will  include  only  one  buffer  with 
its  single  GP  type  control-point.   One  buffer  is  necessary 
since  we  must  have  an  open  network  (CI).   The  single  buf- 
fer will  serve  as  a  destination  address  to  which  foreign 
systems  can  send  messages  in  the  initial  network.   This 
will  permit  messages  to  direct  the  root  process  to  stop  or 
start  and  to  inject  a  program  into  it  which  will  generate 
the-  proper  network.   Arming  GP  control-point  buffers  is  the 
responsibility  of  process  management.   GP  control-point  buf- 
fers are  automatically  disarmed  when  a  process  requests  to 
move  to  a  different  system. 
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Each  control-point  will  have  an  enable  bit  to  indi- 
cate whether  or  not  a  message  should  be  processed  to  cause 
an  interrupt.   A  message  coming  in  for  a  control-point 
which  is  currently  demanding  will  not  affect  it  until  it 
ceases  demanding.   This  permits  the  subprocessor  designer 
to  know  that  there  will  be  no  messages  to  be  taken  care  of 
before  the  present  sequence  of  operations  are  completed  and 
the  demand  bit  is  turned  off.   It  will  be  turned  back  on  if 
any  messages  are  pending.   PR  and  AO  control-points  are  al- 
ways enabled,  GP  control-points  will  be  under  GP  program 
control  by  the  process  designer. 

The  last  item  to  be  included  with  each  control- 
point  will  be  a  del 1 ve r  o r de r  bit.   When  a  control-point 
(with  priority  high  enough  to  interrupt  another  ES/CP 
pair  and  enabled)  is  in  receipt  of  one  or  more  messages, 
the  system  processor  must  decide  which  message  to  deliver. 
Since  the  buffers  are  individually  named,  a  priority  can 
be  associated  with  each  of  them.   The  system  processor  can 
then  deliver  either  the  highest  priority  buffered  message 
or  all  such  buffered  messages  for  that  control-point.   No 
reason  hat  been  found  to  choose  one  delivery  method  over 
the  other  so  both  will  be  permitted.   The  deliver  order 
bit  provides  process  management  control  over  which  method 
will  be  used.   Both  AO  and  PR  will  always  receive  multiple 
messages. 
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A  problem  Is  introduced  when  a  modification  oper- 
ator introduces  a  new  system  into  the  network  definition. 
Potentially  the  new  system  could  send  a  process  to  all 
other  systems  before  each  system  has  the  required  PR  buf- 
fer for  the  new  system.   The  design  must  ensure  that  a 
process  not  be  lost  in  this  way*   Since  modification  oper- 
ators must  be  executed  local  to  the  system  being  modified 
(N5),  a  modify  operator  changing  each  PR  control-point  buf- 
fer set  must  be  executed  in  each  system.   A  PR  process  there- 
fore will  not  transmit  to  any  other  system  until  it  Is  in- 
formed by  a  message  from  the  PR  process  in  each  other  sys- 
tem, that  the  buffer  has  been  created. 

The  initial  network  definition  as  presented  above 
will  be  formally  defined  in  Appendix  C.   In  addition, 
since  it  is  not  very  enlightening  because  of  Its  simplicity, 
Appendix  C  will  also  present  a  two  system  network  defini- 
tion, with  additional  process  states  and  control-points  to 
illustrate  better  the  network  design. 
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For  the  designer  of  advanced  informa- 
tion systems,  a  vital  requirement  of  any 
operating  system  is  that  it  allows  him  to 
change  the  mode  of  operation  it  controls; 
otherwise  his  freedom  of  design  can  be  ser- 
iously limited.   (Per  Brinch  Hansen  (ed. )  - 
Ha  71a,  p.  13) 


CHAPTER  k 
SYSTEM  COMPARISONS 

Summary  of  Network  S tructures 

J j  my  features  of  the  design  presented  in  this  thesis 
have  been  used  in  other  designs.   The  usefulness  of  this  de- 
sign arises  chiefly  because  of  its  organization  which  pro- 
vides process  state  structures  and  defines  operations  on 
these  structures  which  permits  the  delegation  of  authority 
and  responsibility  over  process  behavior  to  the  appropriate 
interacting  agent.   Most  contemporary  operating  system  pro- 
blems are  thus  either  circumvented  or  solved  with  only  mini- 
mal constraints  being  placed  on  the  users.   The  generality 
of  our  network  makes  it  a  useful  model  for  studying  other 
system  designs.   This  section  will  summarize  the  relevant 
properties  which  a  network,  as  described  in  chapter  three, 
would  possess.   The  next  section  will  discuss,  and  compare 
with  our  network,  two  systems  which  use  a  hierarchial  pro- 
cess structure  (RC^IOOO  and  TENEX)  and  one  general  network 
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(ARPA).   The  final  two  sections  of  this  chapter  will  discuss 
some  further  research,  and  summarize  what  this  thesis  has 
accomplished  along  with  some  of  the  benefits  to  be  gained 
from  it. 

The  previous  chapters  presented  the  design  of  a  logi- 
cal network  which  will  support  well-defined  processes.   If 
the  processes  were  not  well-defined,  investigation  into  the 
properties  of  the  network  and  the  processes  it  will  support 
\     tld  be  difficult,  if  not  impossible.   The  whole  design 
must  be  well-defined  if  useful  services  and  facilities  are 
to  be  developed.   If  the  network  is  not  well-defined,  guar- 
anteeing its  present  logical  properties  would  be  difficult. 

The  initial  design  cannot  be  expected  to  include  all 
future  concepts;  therefore  it  must  be  designed  so  some  of  the 
design  responsibilities  can  be  delegated  to  future  designers. 
Users  must  be  delegated  responsibility  for  the  control  of 
process  behavior.   The  network  designer  cannot  hope  to  fore- 
cast what  all  potential  users  of  the  network  will  want  to  do 
or  what  algorithms  will  be  necessary  to  manage  the  processes 
they  create.   Only  the  users  know  what  they  expect  their 
processes  to  do.   For  the  delegation  of  design  responsibili- 
ties to  be  successful,  the  processing  components  (network, 
system,  subprocessor) ,  and  interactions  between  them  and 
the  processes  running  on  the  network  must  be  clearly  defined. 
The  delegation  of  responsibility  for  the  control  of  process 
behavior  is  only  possible  if  process,  process  state,  and 
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process  step  are  clearly  understood,  along  with  intraprocess 
and  interprocess  interactions.   Since  processes  may  attempt 
to  become  uncooperative,  the  network  must  provide  to  the 
user  facilities  for  the  management  of  such  processes.   If 
interesting  applications  are  to  be  developed,  general  pro- 
cess state  structures  and  transformations  on  these  struc- 
tures must  be  provided.   If  any  significant  software  stabil- 
ity is  to  exist,  the  design  must  be  machine  and  technology 
independent. 

A  network  is  defined  as  a  set  of  asynchronous  (no 
definition  of  the  relative  speeds  at  which  the  systems  are 
carrying  out  their  operations)  interacting  digital  systems. 
Interactions  between  them  are  possible  only  using  broadcast 
messages  (message  transmission  occurs  without  regard  for  the 
state  of  the-  destination  system,  as  with  asynchronous  inter- 
rupts) . 

The  logical  network  that  a  user  will  see  is  being  de- 
signed here,  not  the  physical  systems  upon  which  the  defini- 
tion will  be  implemented.   For  example,  since  the  design 
does  not  constrain  the  relative  speeds  of  the  network  sys- 
tems nor  how  messages  are  physically  moved  from  one  system 
to  another,  the  implementer  is  free  to  use  whatever  tech- 
niques and  protocols  are  desirable.   What  physically  happens 
between  the  time  when  one  logical  system  transmits  a  message 
and  the  other  logical  system  receives  it,  or  how  long  the 
procedure  takes  is  the  implement erf s  business  and  not  part 
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of  the  network  design. 

Dealing  with  logically  asynchronous  systems  has  the 
advantage  that  Individual  system  designers  and  implementers 
need  net  be  concerned  with  what  other  systems  are  doing,  ex- 
cept for  the  asynchronous  communication.   On  the  other  hand, 
if  the  users  want  logical  synchronization  between  processes 
running  on  different  systems  in  the  network,  they  must  ac- 
complish it  using  asynchronous  interprocesses  communications, 
rather  than  by  relying  on  synchronization  of  the  steps  of 
the  systems  (intersystem  lockstep  is  not  defined  in  the  net- 
work) . 

The  operations  of  each  network  system  are  carried  out 
by  a  system  processor  which  includes  a  set  of  subprocesors 
that  carry  out  transformations  on  the  expression-states  with- 
in a  process  state.   System  processor  execution  takes  pla 
in  three  phases:   subprocessor  allocation,  subprocessor 
application,  and  message  dispatching.   Each  process  in  the 
network  has  a  single  process  state  (contained  in  one  system 
at  a  time)  and  is  said  to  undergo  one  process  step  each  time 
a  subprocessor  is  applied  to  that  state.   A  process  step  be- 
comes the  only  invariant  measure  of  "time"  in  the  network. 

The  system  processor  will  use  Information  contained 
in  the  process  state  to  apply  subprocessors,  but  will  apply 
only  one  subprocessor  to  a  process  state  each  process  step. 
Since  only  one  system  processor  has  access  to  a  process 
state  at  a  time,  subprocessor  application  becomes  an  opera- 
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tion  local  to  that  system. 

Subprocessor  designers  do  not  have  to  be  concerned 
with  race  conditions  due  to  simultaneous  access  to  a  process 
state  because  only  one  subprocessor  is  applied  to  it  each 
process  step.   The  design  of  subprocessor  operations  which 
require  more  than  one  process  step,  must  still  solve  race 
problems.   Interrupts  might  occur  between  process  steps 5 
causing  a  different  subprocessor  to  be  applied,  or  the  same 
subprocessor  to  be  applied  to  a  different  part  of  the  process 
state.   If  process  designers  choose  to  permit  Interrupts, 
they  must  take  the  appropriate  actions  to  ensure  that  the 
occurrence  of  an  interrupt  does  not  have  an  improper  effect 
on  the-  process. 

Each  process  state  is  composed  of  a  set  of  typed  ex- 
pression-states (EC) s  soma  of  which  may  be  paired  with  con- 
trol-points (CP)  to  form  ES/CP  pairs.   All  transformations 
local  to  a  process  state  are  carried  out  by  the  subproces- 
sors.   An  operation  is  local  to  a  process  state  if  the  pro- 
cess state  contains  all  of  the  information  necessary  for  the 
operation  and  if  the  effects  of  the  transformation  are  con- 
tained in  that  same  process  state „   Expression-states  con- 
tain all  of  the  information  necessary  for  subprocessor 
operation.   All  operations  which  are  not  local  to  a  process 
state  are  carried  out  by  the  system  processor  using  informa- 
tion associated  with  the  control-points. 

The  system  processor  only  accesses  control-point 
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Information  and  not  information  in  expression  states,  there- 
fore the  internal  structure  of  expression-states  can  be  made 
subprocessor  dependent.   Certain  expression-states  may  be 
interpretable  by  only  a  subset  of  the  subprocessors  in  the 
network.   Subprocessors  are  constrained  from  arbitrarily 
accessing  a  type  of  expression-state  other  than  their  own. 
If  a  subprocessor  designer  wishes  for  it  to  have  access  to 
another  expression-state  type,  then  the  subprocessor  must 
be  designed  to  abide  by  the  conventions  laid  down  by  the 
designer  of  the  other  expression-state. 

The  second  part  of  an  ES/CP  pair  is  a  control-point* 
A  control-point  has  associated  with  it  the  information 
necessary  for  subprocessor  application  (type  of  subproces- 
sor to  be  applied,  priority,  demand  bit)  and  interprocess 
communication  (unique  name,  destination  buffers  with  arm 
bits,  enable  bit).   Control-points  provide  a  common  inter- 
face for  interaction  between  subprocessors  and  the  system 
processor. 

Process  designers  use  the  demand  bit  to  request  that 
a  subprocessor  be  applied  to  that  ES/CP  pair.   It  may  be  set 
locally  by  a  subprocessor  operating  on  the  containing  pro- 
cess state  or  because  of  the  receipt  of  a  message  destined 
for  that  control-point.   If  more  than  one  ES/CP  pair  lias 
its  demand  bit  on,  the  system  processor  uses  the  priority 
associated  with  each  control-point  (priority  assignment  is 
static  and  arranged  so  no  intraprocess  conflicts  can  occur) 
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to  determine  which  pair  should  cause  a  subprocessor  to  be 
applied,  and  then  uses  that  pair's  control-point  to  deter- 
mine which  subprocessor  to  apply. 

Control-points  are  recognizable  by  all  system  pro- 
cessors so  that  it  is  possible  to  move  a  process  from  one 
system  to  another  without  concern  over  how  to  cause  sub- 
processors  to  be  applied.   (Note:   All  systems  are  not  re- 
quired to  contain  all  subprocessors,  each  system  processor 
applies  only  those  it  knows  about.)   The  user  is  thus  free 
to  move  a  process  from  one  system  to  another  to  gain  access 
to  special  subprocessors. 

Interrupts  and  faults  are  clearly  distinguishable 
in  the  design.   An  Interrupt  occurs  within  a  process  be- 
cause the  demand  bit  of  a  higher  priority  control-point  was 
turned  on.   Such  occurrences  only  affect  the  decision  of 
which  subprocessor  to  apply  on  the  next  process  step  and 
do  not  cause  pre-emption  of  a  subprocessor  executing  a  pro- 
cess step.   Faults  5,  on  the  other  hand,  occur  during  a  pro- 
cess step  and  cause  an  executing  subprocessor  to  change  its 
program  interpretation  sequence.   Faults  have  no  direct 
effect  on  which  subprocessor  will  be  applied  on  the  next 
process  step. 

Single  Interprocess  messages  are  generated  by  sub- 
processors  during  the  subprocessor  application  phase  of  the 
system  processor.   They  are  placed  in  the  interface  buffer 
along  with  a  destination  address  (CP  name,  buffer  name). 
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During  the  message  dispatching  phase,  the  system  processor 
will  remove  the  message  and  transmit  it.   The  destination 
system  (containing  the  process  state  with  the  destination 
CP  in  it)  will  look  at  the  appropriate  buffer  (a  static 
number  are  associated  with  each  control-point  and  are  named 
individually)  to  see  if  it  is  armed.   If  the  buffer  is  armed, 
the  message  will  be  buffered  (overwriting  any  previous 
message)  and  if  not  armed  the  message  will  be  disregarded. 

Also  associated  with  each  control-point  is  an  ena; 
bit  which  enables  sending  messages  to  cause  an  interrupt. 
If  the  control-point  is  enabled  and  of  appropriate  prior- 
ity, the  system  processor  will  place  a  pending  message  in 
the  interface  buffer  on  the  message  delivery  phase  and  apply 
the  appropriate  subprocessor  on  the  subprocessor  application 
phase. 

Since  control-point  names  are  unique  and  serve  as 
destination  addresses  for  messages,  it  is  not  necessary  for 
the  sender  to  know  either  the  system  in  which  the  destina- 
tion process  resides  or  even  the  process  Itself.   Processes 
can  thus  be  moved  between  systems  without  a  need  to  arran; 
a  new  communication  link.   The  control-point  itself  could 
even  be  moved  to  a  different  process  without  a  transmitting 
process  knowing  the  difference. 

The  relationship  between  the  processes  in  the  net- 
work looks  like  a  tree  and  defines  their  hierarchy  of 
responsibility  and  control  over  descendent  processes  which 
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may  be  distributed  arbitrarily  over  the  network.   Each  net- 
work system  will  have  an  AO  subprocessor  (identical  in  all 
systems)  which  will  account  for  certain  objects s  and  enforce 
restrictions  placed  on  them;  each  process  will  contain  an 
ES/CP  pair  upon  which  the  AO  subprocessor  operates.   The 
AO  control-point  always  has  the  highest  priority  in  the 
process  which  makes  it  impossible  for  the  AO  services  in  a 
process  to  be  uncooperative  with  its  parent.   The  AO  sub- 
processor  cannot  be  locked  out  since  a  message  to  the  AO 
ES/CP  pair  will  always  interrupt  all  other  pairs  in  that 
process. 

All  accountable  objects  will  be  maintained  in  the 
AO  expression  state.   This  gives  the  AO  subprocessor  de- 
signer control  over  the  mechanisms  used  to  access  themc 
Some  of  the  accountable  objects  may  represent  rights  to 
carry  out  certain  operations.   Each  control-point  is  an 
accountable  object.   This  permits  a  parent  to  control  which 
subprocessors  a  child  can  use  since  subprocessor  type  Is 
associated  with  the  control-point.   A  parent  can  control  a 
child's  message  transmission  capability  by  rights  to  trans- 
mit to  particular  control-point  buffers .   Rights  to  move  a 
process  or  execute  a  particular  subprocessor  operator  may 
also  be  included.   In  addition  to  rights,  accountable  objects 
may  contain  logical  objects  such  as  files.   The  set  of  ac- 
countable objects  can  be  thought  of  as  representing  the 
logical  capabilities  of  a  process. 
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In  addition  to  the  AO  subprocessor,  there  will  be  at 
least  two  other  subprocessors  (GP,  PR)  contained  in  each 
system.   The  OP  will  provide  general  programming  services 
and  access  to  all  the  initial  network  services  by  interpret- 
ing a  common  language.   Without  one  such  common  subprocessor 
in  the  network,  process  intersystem  movement  might  not  be 
very  useful. 

The  PR  will  provide  process  state  receipt,  transmis- 
sion, and  creation  services  in  each  system.   Communication 
between  the  processes  in  the  network  and  systems  forei; 
to  the  network  is  also  permitted  using  normal  interprocess 
communication  mechanisms.   The  set  of  accountable  objects 
may  contain  rights  to  transmit  to  control-points  which 
exist  only  in  foreign  systems,  and  certain  control-points 
will  be  permitted  to  have  buffers  to  which  only  foreign 
systems  transmit.   No  special  mechanisms  are  required  to  per- 
mit a  process  to  interact  freely  with  some  outside  agent. 

Use  as  a  Model 

The  network  was  designed  to  be  general  in  the  sense 
that  it  contains  the  concepts  of  most  other  systems.   This 
section  will  model  three  current  systems  using  the  designed 
network  to  show  that  such  models  exist  and  to  relate  the 
three  system  structures.   These  systems  do  not  completely 
meet  our  needs  (they  were  designed  for  different  goals). 
TENEX  (BB71)  and  the  RC'1000  (Ha  70,  Ha  71a)  system  will  be 
described  first,  as  examples  of  systems  which  give  users  the 
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ability  to  create  and  control  a  "process"  hierarchy.   The 
ARPA  network  (CC  70,  CH  72,  TH  72)  will  be  used  as  an  ex- 
ample of  a  distributive  network  composed  of  different  types 
of  computers. 

TEHEX  is  a  time-sharing  system  Implemented  on  an 
augmented  DEC  PDP-10.   It  is  the  logical  structure  as  seen 
by  the  user  that  is  to  be  modeled f  not  the  implementation 
of  it.   Three  examples  of  the  many  alternative  ways  that 
TENEX  could  be  described  in  our  terms  are  shown  in  Figures 
1,  2  and  3»   Boxes  in  the  Figures  represent  our  asynchron- 
systems,  circles  represent  our  process  state,  and  the  lines 
joining  them  represent  the  process  hierarchy.   In  Fig.  3 
each  set  of  parentheses  represents  an  expression-state. 
We  might  first  describe  TENEX  as  a  process  tree  distributed 
over  a  set  of  asynchronous  systems,  each  system  (box)  con- 
taining one  process  (circle).   (Fig.  1).   Since  we  would 
thus  have  only  one  process  in  each  system  and  since  TENEX 
processes  have  no  well-defined  structure  below  process  state 
(like  our  expression  state),  we  would  need  no  structure  be- 
low the  system  process  and  would  consider  the  user  process 
to  be  the  system  process  as  well.   The  Monitor  (running  on 
the  real  system)  can  be  thought  of  as  the  root  process  of 
a  single  process  tree.   The  monitor  process  creates  an 
asynchronous  command  system  with  an  EXEC  process  in  it  for 
each  new  job,  which  then  serves  as  the  top  of  that  job's 
process  tree.   We  would  not  consider  this  system  a  TENEX 
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virtual  system  since  from  the  user's  point  of  view  it  inter- 
prets the  command  language  and  not  the  language  of  the  TENEX 
virtual  machine.   For  each  job  process  below  the  EXEC  we 
would  create  a  system  containing  a.  TENEX  subprocessor. 

Model  one  puts  each  TENEX  process  in  a  separate 
asynchronous  system.   In  model  two  the  whole  process  tree 
is  contained  in  one  system  with  each  TENEX  process  being 
represented  by  one  of  our  processes,  while  in  model  three 
the  whole  process  tree  has  been  collapsed  into  one  process, 
each  TENEX  process  being  represented  as  one  expression 
state.   Three  subprocessors  (schedule,  command,  TENEX)  are 
contained  in  the  single  system  in  models  two  and  three,  in- 
stead of  one  subprocessor  for  each  system  as  in  model  one. 

It  might  appear  that  the  multisystem  model  of  TENEX 
is  better  than  the  other  two  since  it  maps  each  TENEX  vir- 
tual system  onto  one  of  our  asynchronous  systems.   Although 
this  may  be  the  appearance  they  wished  the  system  to  have, 
in  fact  it  is  not  what  exists.   This  model  completely  hides 
the  presence  of  the  time-sharing  algorithm  (we  say  nothing 
about  the  relative  speed  of  asynchronous  systems)  and  the 
sharing  of  memory  by  TENEX  virtual  systems  (our  asynchronous 
systems  do  not  logically  share  memory). 

In  the  first  and  second  models  we  can  explicitly 
represent  the  time-sharing  algorithm  by  the  introduction  of 
an  extra  ES/CP  pair  (highest  priority)  in  each  process  and 
a  time-sharing  process  at  the  top  of  the  process  tree  to 
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receive  clock  signals  and  monitor  messages  for  controlling 
the  schedule.   The  T/s  process  would  Interrupt  the  executing 
Process  by  sending  a  message  to  the  extra  pair.   The  message 
could  include  the  next  process  to  run  so  that  as  soon  as  the 
demand  bits  and  enable  bits  for  any  control-points  in  the 
Process  had  been  turned  off,  the  extra  pair  would  send  a 
message  to  the  extra  pair  in  the  next  process  to  run. 

One  way  of  representing  shared  space  in  models  one 
and  two  is  to  represent  all  space  shared  by  TENEX  processes 
as  an  object  message  and  transmit  it  along  with  the  wakeup 
message. This  is  .  good  model  in  tho  senag   ^  ^  ^.^ ^ 

ties  shared  memory  to  access  to  a  subprocessor,  but  it  hides 
the  relationships  between  the  processes  doing  the  sharing. 
Model  three  not  only  can  represent  the  time  sharing  algo- 
rithm but  also  the  sharing  of  space.   The  T/S  pair  „ould 
receive  the  monitor  and  clock  Information  and  manipulate 
the  control-points  associated  with  the -TEHEX  processes  to 
execute  the  scheduling,   since  expression  states  within  our 
Processes  are  permitted  to  share  address  space  and  the  sys- 
tem processor  applies  only  one  subprocessor  at  a  time  to  a 
Process  state,  model  three  provides  an  exact  representation 
of  TENEX  in  our  terms. 

In  each  of  the  three  models  the  TEHEX  -pseudo"  inter- 
rupt, as  they  call  it,  could  be  represented  either  as  an  in- 
terrupt or  as  a  fault.   If  we  used  our  interrupt  mechanism 
«  would  say  that  each  TEHEX  process  has  two  control -points 
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associated  with  it.   A  higher  priority  control-point  would 
interrupt  the  process  when  pseudo-interrupt  messages  were 
received  from  the  monitor.   The  lower  priority  control- 
point  would  be  used  for  the  normal  processing,  including 
the  receipt  of  wakeup  messages  after  certain  monitor  calls. 

The  alternative  is  to  describe  each  TENEX  process 
with  only  one  control-point,  representing  the  pseudo-inter- 
rupts  as  faults  delivered  by  the  Implementation  to  the  sub- 
processor  being  applied.   The  interrupt  models  nicely  the 
fact  that  certain  of  the  events  are  truly  asynchronous  with 
respect  to  a  processes  execution  (from  terminals,  other 
processes)  but  the  fault  models  nicely  those  events  which 
are  a  result  of  a  local  execution  (arithmetic).   Since  the 
TENEX  virtual  machine  does  not  clearly  distinguish  between 
interrupts  and  faults  as  we  have  in  our  system,  either 
solution  would  be  sufficient  as  a  model  of  TENEX.   In  all 
three  models  using  the  interrupt  mechanism,  a  hierarchial 
subprocessor  application  scheme  would  be  used  to  determine 
how  to  apply  the  subprocessors  to  the  process  states. 

There  are  almost  no  accountable  objects  manipulated 
by  job  processes  in  TENEX  since  the  time-sharing  implemen- 
tation attempts  to  allocate  to  each  TENEX  process  its  "fair 
share"  of  physical  resources.   A  major  difference  between 
TENEX  and  our  system  is  that  we  have  introduced  accountable 
objects  and  the  AO  subprocessor  to  provide  a  mechanism  for 
a  parent  process  to  use  if  it  wishes  to  allocate  some  of  its 
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accountable  object  to  its  children  while  maintaining  con- 
'  trol  over  the  use  of  them.   The  ability  to  receive  pseudo- 
interrupts  in  TENEX  can  be  thought  of  as  an  accountable  ob- 
ject in  the  sense  that  a  parent  has  the  right  to  field  in- 
terrupts for  its  children.   One  of  the  major  consequences 
of  not  having  accountable  objects  is  that  TENEX  is  not 
really  able  to  support  a  hierarchy  of  operating  systems. 

There  are  several  features  of  our  network  which  are 
not  present  in  TENEX.   The  TENEX  virtual  machine  is  as  com- 
plex as  their  concept  of  system  can  get  and  in  it  there  is 
no  concept  of  lockstep  process  transformations  which  we  get 
when  multiple  processes  reside  in  one  of  our  systems.   TENEX 
also  does  not  have  the  complex  process  states  we  can  con- 
struct using  multiple  expression  states  (Model  3).   The 
authors  of  "TENEX,  a  paged  time  sharing  system  for  the 
PDP-10"  (BB  71)  use,  as  an  example  to  illustrate  the  useful- 
ness of  TENEX 's  structures,  a  program  wishing  to  wait  for 
terminal  input  but  only  for  a  specified  length  of  time.   Two 
processes  are  created,  one  waiting  for  the  input  and  one 
waiting  for  the  timer.   V/e  could  solve  this  same  problem 
using  two  ES/CP  pairs  within  the  same  process  rather  than 
two  processes.   The  process  could  even  be  doing  some  addi- 
tional processing  using  a  third  lower  priority  ES/CP  pair 
and  still  be  interrupted  when  either  of  the  two  events  oc- 
curred. 

Whereas  we  can  model  their  system  with  its  time- 
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sharing  algorithm,  they  could  not  hide  the  fact  that  they 
are  a  time  sharing  system  if  they  were  to  try  and  model  our 
system.   The  TENEX  structures  are  designed  for  single  sys- 
tem interprocess  interactions.   Even  these  are  highly  con- 
strained between  jobs  in  the  same  system,  whereas  our  normal 
interprocess  communication  structures  are  the  same  no  matter 
what  the  residence  of  the  processes  carrying  out  the  inter- 
action ,   Since  our  processes  are  free  to  move  between  sys- 
tems in  the  network,  we  have  not  permitted  processes  to 
share  address  space  except  through  explicit  transfer  of  the 
information  (by  the  process  not  the  system).   With  respect 
to  our  goals,  TENEX  is  most  lacking  in  the  facilities  pro- 
vided for  user  management  of  potentially  uncooperative  pro- 
cesses . 

The  RC^tOOQ  multiprogramming  system  developed  by  Re- 
gencentralen  was  designed  to  "be  extended  with  a  hierarchy 
of  operating  systems.  .  . "  (Ha  70).   Resources  are  allocated 
recursively  by  a  parent  process  to  its  children.   The  RC'JOOO 
system  can  be  represented  in  our  design  as  a  single  system 
containing  one  process  state,  similar  to  the  third  TENEX 
model  (Pig.  3).   Instead  of  the  three  subprocessors  in  the 
TENEX  model  we  can  describe  the  RC'tOOO  system  with  only  one. 
The  single  process  state  will  be  composed  of  a  scheduling 
expression-state  and  one  expression-state  for  each  RC4000 
process  currently  residing  in  core. 

Since  expression-states  may  share  address  space,  the 
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decision  to  model  the  RC^OOO  system  with  one  process  state 

permits  us  to  model  explicitly  the  potential  overlap  of  ad- 
dressing capabilities  between  RCHoqq   processes  in  core  at 
any  given  time  (keyed  access  is  used).   Those  RC4000  pro- 
cesses which  are  currently  stopped  would  exist  as  data  ob- 
jects in  the  expression-state  representing  their  parent 
process.   This  is  the  way  the  rc'1000  system  permits  a  parent 
to  deal  with  them. 

Our  model  would  associate  a  control-point  with  each 
expression-state  (RCiJOOO  process),  plus  one  attached  to  the 
scheduling  expression-state  which  would  have  the  highest 
priority.   The  association  of  a  control-point  with  the  ex- 
pression-states representing  RC4000  processes  is  necessary 
since  each  process  may  have  messages  directed  to  it  by  other 
processes  in  the  system.   Each  RC4000  process  needs  only 
one  control-point  associated  with  it  since  there  is  no  con- 
cept of  our  interrupt  in  their  system,  as  the  user  sees  it. 
Their  internal  interrupts  are  represented  by  our  faults. 
"Wait"  operations  control  RC'IOOO  process  execution  by  turn- 
ing off  the  demand  bit  associated  with  the  single  control- 
point.   After  completion  of  the  operation,  the  scheduler 
turns  on  the  demand  bit  and  execution  continues  where  it  had 
left  off  before  the  wait.   It  is  this  simple  behavior  of 
the  RC'JOOO  process  that  permits  us  to  represent  it  as  a 
single  expression-state  with  one  control-point  attached. 
If  we  knew  that  the  address  spaces  of  all  RC4000 


process  were  disjoint,  then  we  would  represent  each  one  of 
them  by  one  of  our  processes  containing  one  AO  expression- 
state  and  one  processing  expression-state.  The  AO  expres- 
sion-state would  perform  the  parent's  breakpoint  operations, 
insure  that  resources  were  allocated  properly,  and  perform 
the  scheduling  function  as  discussed  in  the  TENEX  model. 

There  are  two  additional  ways  we  might  represent 
shared  space  in  our  models  and  still  use  multiple  process 
states,  without  sending  a  shared  space  object  along  with 
the  scheduling  message  as  was  done  in  the  TENEX  model.   We 
could  consider  the  shared  space  to  be  maintained  by  either 
a  "shared  space"  process  or  foreign  system,  and  have  the 
sharing  processes  communicate  their  requests  to  these 
agents.   Although  this  would  adequately  simulate  the  ef- 
fects of  shared  space,  it  would  introduce  the  artifice  of 
using  interprocess  interactions  to  accomplish  it. 

The  implementation  of  memory  sharing  mechanisms  us- 
ually involves  either  a  foreign  system  (shared  memory  mod- 
ules with  conflict  resolution  on  requests)  or  the  process 
mechanism  (monitor  calls  which  insure  that  only  one  process 
at  a  time  accesses  the  information).   These  models,  of 
course,  are  simply  models  of  low  level  system  structures 
for  normal  hardware  systems.   A  machine  independent  virtual 
system  structure  must  not  be  sensitive  to  such  low  level 
details. 

"P  &  V"  operations  can  be  modeled  nicely  using 
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either  of  these  mechanisms,  although  in  our  system  17 e  could 
provide  more  control  over  the  sharing  since  the  process 
address  spaces  would  be  disjoint  and  we  could  prevent  in- 
valid entries.   In  our  model,  sufficient  control  over  this 
potentially  uncooperative  behavior  could  be  achieved  by 
explicitly  defining  the  shared  space  process  to  supply  the 
information  properly  even  if  the  P  &  V  operations  were  not 
used.   Uncooperative  processes  cannot  be  prevented  from 
accessing  shared  space  by  using  only  cooperative  "P  &  V" 
operations.   This  mechanism  is  thus  useful  but  not  suffi- 
cient for  process  control. 

There  are  two  important  differences  between  the 
RC^iOOO  system  and  TENEX  with  respect  to  their  treatments  of 
resources  and  interprocess  messages.   The  RC^tOOO  system 
makes  explicit  use  of  recursive  resource  allocation.   Part 
of  the  procedure  for  creating  a  child  process  involves  the 
explicit  allocation  of  some  of  the  parent's  resources  (al- 
ways a  subset).   A  TENEX  process  can  control  the  execution 
and  existence  of  its  children,  and  field  pseudo-interrupl-n 
for  them,  but  it  does  not  specifically  allocate  resources 
to  them.   All  TENEX  resource  allocation  is  based  on  a  "fair 
share"  algorithm  built  into  the  implementation. 

In  our  single  process  model  of  the  RC'IOOO,  the  re- 
source allocation  would  be  represented  by  creating  the 
child  expression-state  with  access  to  objects  representing 
the  proper  allocation  of  resources.   In  our  multiprocess 
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model >  each  process  (representing  a  RC^OOO  process)  would 
maintain  the  information  about  that  process's  allocation  of 
resources  in  the  AO  expression-state,  which  we  use  for  our 
recursive  allocation  of  accountable  objects. 

In  both  the  RC'lOOO  system  and  our  system,  a  parent 
process  recursively  allocates  subsets  of  what  it  has,  but 
there  are  several  important  differences  between  the  mechan- 
isms used.   Our  accountable  objects  are  explicitly  maintained 
in  a  reliable  expression-state  in  each  process  and  we  pro- 
vide a  common  subprocessor  in  each  system  to  operate  on  that 
expression-state.   By  including  the  accountable  object  in- 
formation as  part  of  the  process  state,  it  automatically 
moves  with  the  process.   A  transmitting  system  does  not  have 
to  send  an  additional  message  to  the  receiving  system  con- 
cerning all  of  the  accountable  objects  and  information 
necessary  for  their  accounting  and  protection.   The  common 
subprocessor  reduces  the  complexity  of  each  system  processor 
and  assures  that  each  system  will  invariantly  handle  ac- 
countable objects.   In  contrast,  the  RC'1000  monitor  main- 
tains the  resource  information  and  performs  the  operations 
on  this  information.   The  RC4000  system  does  not  need  to 
keep  the  resource  information  local  to  the  process  state 
since  their  processes  do  not  move  between  systems.   A  spe- 
cial subprocessor  is  not  really  necessary  since  the  resource 
function  can  easily  be  incorporated  into  the  monitor  without 
adding  unnecessary  complexity.   RC'IOOO  resources  are  not 


l-'!7 
really  pre-emptible,  other  than  by  killing  the  child,  and 
a  parent  cannot  explicitly  attach  access  restrictions  to 
their  use.   A  RC4000  process  is  created  with  a  given  set 
of  resources  and  uses  them  at  its  discretion. 

Interprocess  communication  is  handled  differently 
in  the  RC4000  system  and  TENEX.   TENEX  uses  their  pseudo- 
interrupt  and  a  shared  address  space,  but  restricts  such 
interactions  to  the  processes  of  one  job.   An  advantage  of 
the  TENEX  mechanism  is  that  the  pseudo-interrupt  permits  a 
process  to  be  told  a  message  is  pending,  whereas  the  RC^OOO 
system  requires  a  process  to  ask  for  the  message  and  if  it 
is  not  there,  go  to  sleep.   The  RC^IOOO  system  uses  message 
buffers  (a  resource  not  part  of  a  shared  address  space)  and 
permits  a  process  to  communicate  with  any  process  it  knows 
about.   The  advantage  of  the  RC^IOOO  mechanism  over  TENEX  is 
that  it  does  not  require  shared  space;  more  than  one  message 
can  be  sent  at  a  tirnej  and  no  restriction  is  placed  on  how 
many  different  processes  can  be  transmitting  to  one  receiv- 
ing process. 

Our  communication  mechanisms  have  an  interrupt  abili- 
ty and  do  not  use  shared  space.   We  associate  multiple  buf- 
fers with  a  destination  control-point  and  consider  the  right 
to  transmit  to  a  particular  one  of  these  buffers  as  the 
accountable  object,  not  the  buffer  itself.   We  thus  control 
the  right  to  transmit  to  a  particular  destination  while  they 
only  control  the  means  of  communication  and  not  who  can  be 
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Although  both  TENEX  and  the  RC*J000  systems  are  mono- 
processor  systems,  the  system  structure  they  use  could  be 
extended  to  a  multi-processor  level.   Appropriate  subpro- 
cessor  application  rules  would  have  to  be  instituted  and  all 
primitive  operators  implemented  so  they  v/ould  leave  the  user 
processes  well-defined,  regardless  of  the  number  of  subpro- 
cessors  operating  concurrently  in  the  system.   Most  of  the 
difficulties  to  be  faced  would  arise  because  the  user  pro- 
cesses can  share  space  and  because  of  system  race  conditions 
for  process  state  information.   These  are  basic  problems 
that  drastically  effect  the  structure  and  efficiency  of  si 
an  extension o   The  extension  to  a  network  or  system  would  be 
very  difficult  and  would  severely  constrain  user  management 
of  processes.   In  our  system,  process  states  are  disjoint, 
only  one  subprocessor  is  applied  to  a  process  state  each 
process  step,  and  external  interactions  with  a  process  do 
not  occur  during  a  process  step.   Subprocessor  designers 
therefore  do  not  have  to  be  concerned  with  resolving  race 
conditions  for  shared  access  since  it  never  occurs. 

We  want  to  briefly  look  at  computer  networks .   The 
most  degenerate  form  of  our  netv/ork  structures  would  be 
achieved  by  connecting  a  set  of  systems  together  without 
defining  their  system  structures  or  placing  restrictions 
on  their  interactions,  other  than  with  which  other  systems 
they  can  communicate.   Such  a  network  would  be  defined  as 
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a  set  of  autonomous  interacting  foreign  systems.   The  net- 
work designers  can  say  very  little  about  the  processes  run- 
ning in  such  a  network.   Only  the  set  of  systems  with  which 
a  process  can  communicate  would  be  known.   Nevertheless, 
this  degenerate  network  is  a  good  model  for  the  ARPA  Com- 
puter Network  (ARPANET). 

ARPANET  provides  "for  the  interconnection,  via 
common-carrier  circuits,  of  dissimilar  computers  at  wide- 
ly separated"  centers  (OH  72).   Protocols  (agreements  on 
the  format  and  relative  sequences  of  messap^es  to  be  ex- 
changed) were  designed  as  a  layered  hierarchy  so  each  level 
does  not  have  to  be  concerned  with  the  intricacies  of  the 
lower  levels  (CH  72).   The  lowest  level  of  the  hierarchy 
is  the  message  exchange  between  the  Interface  Message  Pro- 
cessors (IMPs),  and  the  highest  level  is  the  user  procei 
to  process  communication. 

In  contrast  with  the  degenerate  network  above,  we 
can  model  the  ARPANET  IMPs  as  a  network  whose  processes 
interact  with  a  set  of  foreign  systems  (HOSTs).   The  IMP 
processes  are  fully  defined  by  the  network  designers,  the 
users  have  nothing  to  say  about  them.   Although  It  would  be 
possible  for  us  to  model  the  whole  ARPANET  at  any  one  of  the 
above  levels,  it  is  only  the  higher  level  we  wish  to  model 
here.   In  our  terms,  the  ARPANET  HOSTs  can  be  modeled  as  a 
set  of  foreign  systems  supporting  interacting  user  processes. 
In  order  to  understand  the  behavior  of  any  pair  of  these 
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processes,  we  must;  model  each  foreign  system  processor  down 
to  the  application  of  subprocessors.   Those  HOSTs  operating 
under  TENEX  could  be  modeled  using  one  of  the  models  above. 
Similar  models  could  be  developed  for  each  HOST.   Since  the 
process  structure  of  HOSTs  are  not  constrained,  existing 
ones  can  be  changed  and  new  HOSTs  with  new  process  struc- 
tures can  be  added  to  the  network.   Process  behavior  can 
thus  be  defined  only  locally  to  each  system  according  to 
current  structures. 

In  the  ARPANET,  process  behavior  is  dependent  on 
system  residence.   There  is  no  standard  concept  of  process 
step  or  interrupt  since  there  is  no  standard  system  pro- 
cessor.  The  lack  of  standard  structure  requires  independent 
study  of  each  system  model  if  there  is  a  need  to  understand 
their  behavior.   Although  this  is  simplifying  from  the  im- 
plemented point  of  view,  it  is  not  particularly  useful 
from  the  users'  point  of  view.   In  order  for  a  user  to  take 
advantage  of  the  asynchronous  systems  to  construct  an  asyn- 
chronous multiprocess  computation,  the  structures  of  each 
system  to  be  used  must  be  clearly  understood,  and  local 
rules  and  conventions  must  be  used  to  design  and  manage  each 
process , 

The  ARPANET  assumes  no  responsibility  towards  inter- 
acting processes  other  than  providing  the  communication  link 
to  each  operating  system,  just  as  our  design  assumes  no  re- 
sponsibilities towards  a  process  in  a  foreign  system.   There 
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are  no  ARPANET  structures  which  permit  a  user  to  institute 
remote  constraints  on  process  behavior,  and  no  notion  of  tl 
RCilOOO  resource  or  our  accountable  objects.   Processes  in 
separate  systems  may  communicate,  but  delegation  of  re- 
sponsibility and  authority  between  them  must  be  purely  co- 
operative and  subject  to  local  HOST  constraints. 

The  ARPANET  provides  five  interprocess  communication 
Primitives  in  each  HOST  system  Interface.   These  permit, 
via  HOST  operating  systems,  interactions  between  processes 
residing  in  different  HOSTs.   since  there  is  no  standard 
concept  of  either  system  or  process,  a  user  must  understand 
each  local  definition  before  constructing  a  multisystem  com- 
putation.  The  effect  of  using  these  primitives  becomes 
highly  system  sensitive. 

Each  ARPANET  HOST  has  a  set  of  send  and  receive 
sockets  whose  names  have  three  parts:   user  number;  HOST 
number;  and  AEN  (a  seven  bit  number  plus  one  bit  for  send 
or  receive).   Socket  names  are  thus  unique  throughout  the 
network  while  providing  a  pool  of  sockets  for  each  user  at 
each  HOST,   m  order  to  use  these  sockets,  a  process  must 
interface  with  its  local  Network  Control  Program  (NCP), 
which  acts  on  its  behalf  to  establish,  break,  and  switch 
connections.   Once  a  particular  connection  between  two  soc- 
kets has  been  made,  the  process  is  free  to  communicate  using 
that  connection  until  it  is  broken. 

The  ARPANET  designers  used  the  fairly  .static  connec- 


Won  mechanism  because  they  felt  that  processes  would  con- 
duct prolonged  conversations  and  not  one  shot  requests   Al- 
though the  NCP  ensures  that  the  process  requesting  use  of  a 
Particular  socket  to  make  a  connection  has  the  same  user 
"umber  as  the  socket,  once  that  connection  has  been  made  it 

as  possible  to  move  the  connect!  m  (-„ 

<.no  connection  to  a  process  running  under 

a  different  user  number   Thi-   .,<-  i 

numocr.   Thio,  at  least,  means  that  no  other 

«Ser  may  uncooperatively  exhaust  another  user's  pool  of  soc- 
kets, although  the  processes  under  one  user  number  must 
still  be  cooperative  in  their  use  of  sockets  to  make  connec- 
tions.  There  is  also  no  mechanism,  other  than  cooperation 
by  which  a  user  may  control  the  use  of  a  connection  once  it 
has  been  made. 

Thomas  and  Henderson  (TH  72)  describe  a  major  disad- 
vantage of  the  ARPANET  connection  mechanism  as  requiring  a 
Process  to  know  the  socket  number  that  the  other  process 
"HI  be  using  for  its  end  of  the  connection  before  the  con- 
nection can  be  made.   This  implies  knowledge  of  which  HOST 
the  process  v,ill  be  in  and  the  user  number  under  which  it 
will  be  running  as  well  as  the  particular  AEN  to  be  used. 
In  our  design  a  control-points-  name  serves  as  the  destina- 
tion address,  but  although  the  name  is  unique,  it  is  not 
bound  to  a  Particular  system  or  user.   Both  the  control- 
Points  themselves,  and  rights  to  transmit  to  particular 
buffers  associated  with  control-points  are  accountable  ob- 
jects and  therefore  recursively  managed  by  the  process 
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hierarchy.   Our  design  also  leaves  the  actual  making  of  a 
connection  up  to  the  implementers.   If  a  process  has  the 
right  to  transmit  to  a  particular  control-point  buffer,  it 
can  send  a  message  without  becoming  involved  with  making 
the  connection. 

Since  all  system  processors  in  our  network  use  a 
standard  concept  of  process  step,  interrupt,  message  deliv- 
ery, and  standard  operations  on  control-point,  the  user  is 
provided  with  a  consistent  concept  of  process  and  process 
step  and  a  standard  way  to  use  the  services  of  the  network,. 
An  ARPANET  user  must  be  prepared  to  create  all  processes 
local  to  the  system  in  which  they  are  to  run  since  different 
HOSTs  may  have  different  process  structures  and  intersysten 
process  migration  may  not  be  possible.   Our  design,  on  the 
other  hand,  provides  explicitly  for  intersystem  process 
movement  and  provides  for  at  least  one  common  subprocessor 
(GP)  which  will  interpret  a  general  language  and  provide  all 
initial  network  services.   This,  of  course,  doss  not  ensure 
that  a  process,  using  subprocessors  other  than  those  common 
to  all  systems,  will  run  in  any  system  to  which  it  is  moved. 
A  user  thus  has  an  alternative  to  creating  a  different  pro- 
cess in  each  system  and  exchanging  control  and  data  informa- 
tion between  processes.   A  user  can  create  a  "multi-lingual" 
process,  U3e  the  GP  subprocessor  for  common,  services,  and 
move  the  process  from  system  to  system  to  access  special 
subprocessors . 


■  discussion  here  was  intended  to  show  how  the  user- 
level  protocols  compare  with  TENEX,  RC'1000  and  our  system. 
It  should  bs  noted  that  we  could  conveniently  use  these 
ARPANET  protocols  to  implement  our  system  structures  at  each 
HOST.   Our  system  would  thus  become  one  more  level  of  proto- 
col in  the  ARPANET  hierarchy.   ARPANET  deficiencies  largely 
arise  from  the  attempt  to  use  such  an  implementation  struc- 
ture in  place  of  the  virtual  network  that  is  really  required. 

Further  Work 

It  would  be  conceivable  to  answer  questions  concern- 
ing the  generality  of  the  postulated  constraints  by  extend- 
ing this  work  in  several  directions.   One  of  the  first  ex- 
tensions which  comes  to  mind  is  to  include  not  only  systems 
as  components  of  our  network,  but  also  other  networks,  giv- 
ing us  structured  nodes  and  a  hierarchy  of  networks.   Ques- 
tions concerning  the  relationships  between  processes  in  the 
various  levels  of  this  hierarchy  could  be  investigated.   The 
systems  in  one  network  level  might  be  considered  to  be  for- 
eign systems  to  the  processes  in  all  other  levels,  or  per- 
haps a  logical  interface  process  should  be  provided ^through 
which  connections  between  networks  are  maintains    Re- 
sponsibility and  authority  problems  begin  to  surface  again, 
in  partici   t  the  rights  of  processes  in  one  network  with 
respect  to  such  areas  as  modifications  and  manipulations  of 
accountable  objects  (Global  vs.  local  rights). 
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The  sufficiency  of  our  constraints  and  the  correct- 
ness of  our  design  decisions  when  real  time  and  continuous 
(analogue)  processes  are  added  to  the  system  is  also  in  need 
of  investigation.   Does  our  design  remain  invariant  when 
used  for  these  processes,  and  what  can  be  said  about  process 
behavior?   I„  the  case  of  real  time  processes,  the  process 
state  structures  probably  are  not  effected  but  the  relative 
speeds  of  system  will  effect  real  time  process  performanc 
In. the  case  of  continuous  processes,  any  investigation  must 
first  del    what  is  meant  by  continuous  processes,  ho,,  to 
represent  them,  and  how  to  combine  continuous  and  digital 
processes  into  one  model. 

^e  (  ,    ,  m  this  thesis  must  be  extended  to  include 
the  subprocessors  ana  their  modification  operators,  before 

" •  can  bo  produced.   The  GP  subprocessor 

"  to  be  a  programmable  subprocessor  common  to  all  systems 
and  must  provide  all  initial  network  services  within  a 
framewortc  of  a  general  language.   The  design  of  the  AO  sub- 
processor  must  include  investigations  into  classifications 
of  accountable  objects,  operators  for  their  accounting  and 

Lntenance,  and  the  effects  of  process  birth.,  death,  and 
intersystem  movement  on  them.   Investigations  into  network 
modification  operators  must  be  continued  to  determine  the 
forma  they  may  tats  and  the  freedoms  which  can  be  permitted 
for  modifications,  including  modifications  which  are  not 
Just  augmentations. 
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There  are  several  Implementation  questions  which  can 
be  pursued  based  on  this  design.   We  can  exploit  our  know- 
ledge of  the  system  to  study  the  optimization  of  an  imple- 
mentation.  Once  a  prototype  implementation  exists  we  can 
monitor  the  process  behavior  at  both  subprocessor  primitive 
level  and  the  system  processor  operator  level  to  improve  our 
implementation.   We  can  then  study  independent  of  any  par- 
ticular implementation,  the  question  of  practical  machine 
design  including  buffering  and  efficiency  along  with  sub- 
processor  augmentation,  program  type  objects,  and  special 
subprocessors. 

In  addition  to  studying  implementation  questions  we 
can  abstractly  study  the  properties  of  our  formal  defini- 
tion.  A  parallel  effort  is  being  pursued  (Jo  73)  which  is 
intended  to  derive  and  prove  assertions  that  certain  fea- 
tures of  the  state  languages  of  systems  (using  the  defini- 
tion system  in  PH  71)  remain  invariant  to  transformation 
under  that  system  processor.   We  will  then  be  able  to  use 
these  mechanisms  to  investigate  the  formal  definition  of  our 
network  and  the  processes  it  supports.   We  would  hope,  by 
studying  the  network  definition  itself,  to  verify  and  even 
formally  certify  our  design  from  the  point  of  view  that  cer- 
tain of  the  designed  system  process  state  structures  are 
proven  to  be  invariant  under  the  transformations  carried  out 
by  the  system  processors.   Our  design  has  been  "debugged"  by 
test  cases,  using  an  interpreter  for  the  formal  definition 
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system,  but  this  testing  alone  cannot  be  sufficient  to  certi- 
fy that  these  imparlances  remain  so  under  all  transformation. 

Once  the  network  exists,  it  is  clear  that  not  all 
users  will  be  permitted  or  even  will  want  to  use  the  full 
flexibility  of  our  structures.   Investigations  will  be 
needed  to  determine  what  user  operating  environments  should 
be  created  by  using  appropriate  processes  in  the  process 
tree  and  distributed  over  the  network  systems.   Using  the 
hierarchy  we  can  investigate  distributed  vs.  central  con- 
trol, and  various  levels  of  user  freedoms.   We  can  thus 
study  concepts  of  logical  operating  system  structures  and 
commonly  desired  services.   Our  network  provides  an  operat- 
ing system  implementation  language  for  such  studies. 

One  final  area  of  investigation  is  the  development 
of  application  tool,  including  the  various  application  lan- 
guages which  should  be  provided  In  a  network.   We  would  like 
to  develop  a  translator-compiler  (written  in  the  GP  language) 
to  take  some  of  these  languages  and  generate  translators  for 
them,  whose  output  is  the  language  interpreted  by  GP.   This 
would  permit  such  processes  to  be  system  independent  since 
each  system  has  a  GP.   We  „oula  als0  like  to  develop  ^^ 
special  purpose  applications  such  as  distributed  data  base 
and  management  information  system,  and  user  process  heir- 
archies  which  interact  with  special  purpose  foreign  systems. 

Several  of  the  above  items  are  currently  being  In- 
vestigated.  The  initial  de-i-n  or  f-h»  ™  „,  > 

"  uet>ign  oi  the  GP  subprocessor  has 
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been  completed  (Pi  ;2)   and  an  implementation  of  it  exists 
written  in  a  common  subset  of  FORTRAN  IV.   A  Ph.D.  thesis 
(Co  73)  is  under  preparation  to  complete  the  design  of  the 
AO  subprocessor  and  another  student  is  investigating  modi- 
fication operators  (Pa  73).   A  single  physical  system  imple- 
mentatlon  of  one  logical  system  is  in  progress  which  will 
then  be  duplicated  within  that  physical  system  to  give  us 
multiple  logical  systems.   A  movement  to  a  multiple  physical 
system  implementation  of  the. multiple  logical  system  will  be 
attempted  dependent  on  the  completion  of  a  small  physical 
network  being  constructed  at  the  University  of  Wisconsin. 
A  research  seminar  (Spring  73)  is  investigating  the  ques- 
tions of  translator-compilers  and  defining  one  in  the  GP 
language  to  make  it  available  in  each  system.   Most  of  the 
other  projects  have  been  discussed  and  considered  as  future 
work  but  are  not  currently  scheduled  since  they  are  depend- 
ent on  the  work  currently  underway. 

Summary  and  Concliisl  »s 

The  emergence  of  networks  of  digital  computer  systems 
has  resulted  in  severe  problems  concerning  their  managabili- 
ty,  generality  and  portability.   A  manaf;abls  netl,ork  deslgn 
must  provide  for  the  resolution  of  conflicts  of  responsibili- 
ty and  authority.   Generality  must  exist  if  the  network  is 
to  be  useful  to  many  classes  of  potential  users.   Portal  Lli- 
ty  must  be  possible  if  the  network  design  and  user  processes 
are  not  to  be  implementation  dependent. 
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A  sufficient  set  of  postulated  constraints  on  the 
network  design  were  developed  to  permit  a  solution  to  these 
problems.   Difficulties  in  network  manageability  result  pri- 
marily because  of  the  conflicting  goals  of  the  network,  im- 
plementation, and  process  designers.   The  solution  requires 
a  clear  factorization,  between  these  three  agents,  of  the 
responsibility  and  authority  for  controlling  the  behavior 
of  the  processes  running  on  the  network. 

A  design  was  then  carried  out  within  the  postulated 
constraints  to  show  both  that  a  solution  to  the  network  pro- 
blems does  exist  within  these  constraints,  and  that  it  leads 
to  a  design  which  it  is  feasible  to  implement  and  which  is 
general  enough  to  contain  at  least  most  of  the  current  sys- 
tem structures.   A  set  of  derived  constraints  were  devel- 
oped to  explore  in  more  detail  the  consequences  of  the 
postulated  constraints,  and  then  a  set  of  design  decisions 
were  developed  which  defined  the  generality  of  the  struc- 
tures to  be  provided  the  users.   Finally  several  current 
systems  were  modeled  using  the  network  structures  developed 
and  the  structures  themselves  were  formally  defined. 

There  are  many  conclusions  which  could  be  drawn  from 
the  work  presented  here.   Cne  of  the  most  significant  of 
these  is  that  it  was  possible  to  accomplish  such  a  general 
goal,  with  the  result  being  a  clear  solution  which  seems 
to  be  implementable.   This  success  appears  to  be  a  result 
of  having  undertaken  the  whole  problem  of  manageability, 
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generality,  and  portability,  and  not  approaching  only  one 
part  of  it.   The  particular-  factorizations  of  the  problem 
made  in  this  thesis  were  based  on  the  constraints  and  de- 
sign goals  and  not  as  a  result  of  arbitrary  or  conflicting 
decision  as  defined  in  current  systems.   Factorization  of 
responsibility  and  authority  was  the  tool  which  maizes  the 
solution  possible.   It  does  not  appear  that  it  is  sufficient 
to  approach  these  problems  independently  (for  example,  try- 
ing to  solve  the  problem  of  portability  while  leaving  cur- 
>  ■■         tructures  unchanged  and  independent).   It  may 

be  that  because  of  the  interactions  of  th<  se  problems,  a 
»ba]  iclution  such  as  presented  Lri  this  thesis,  is  the 
only  P°asible  path  to  a  gen.     solutj     We  have  she. 
th^t  it  ;:■:   a  sufficient  path. 

As  a  result  of  having  s  set  of  machine  and  technology 
independent    n   1   ns  which  are  at  least  c     Le  of  , 
ing  eurn  it  systems,  it  is  poi  Lble  to  discuss  system  and 
pro "•'"  '  'trust urea  and  compare  them  using  the  network  de- 
sign presented  here.   The  vocabulary  used  is  independent  o 

;  being  described,  and  presents  a  well-defined 
framework  within  which  to  define  problems.   The  concept  of 
a  genera]  process  step  provides  maximum  freedom  to  the  user 
and  designer,  while  providing  sufficient  rules  to  permit 
work  to  bo  actually  accomplished,   Processes  defined  to  run 
on  our  network  systems  will  provide  poi   billty  nor.  only 
between  currently  implemented  systems  but  also  between 
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generations  of  implementations  of  the  current  systems.   Th 
means  that  it  is  now  cost  effective  to  invest  heavily  in 
applications  and  application  tools  since  they  can  survive 
changes  in  technology.   Process  designers  can  define  local 
logical  operating  systems,  including  the  management  of  ac- 
countable objects,  in  distributed  computations  which  are  not 
system  dependent. 

Many  of  the  features  of  the  design  are  interesting 
when  taken  by  themselves  and  need  not  be  applied  only  to  a 
network.   Control-points  combine  the  functions  of  both  com- 
munication and  control  (interrupt)  and  permit  interprocess 
interactions  to  be  directed  to  particular  parts  of  a  pro- 
cess state  and  not  just  the  pro;:-''  itself.   Subprocesses 
and  expression-states  in  conjunct;!  or.  with  control-points, 
permit  the  concept  of  process  step  to  be  {  i  i  ralized.   The 
subprocossor  designer  is  able  to  define  its  state  structures 
and  operations  on  that  state,  thus  deferring  binding  of  po~ 
tentic   process  behavior  indefinitely  since  the  introduction 
of  new  subprocessors  does  not  affect  current  process  be- 
havior,  The  concept  of  accountable  objects,  and  their 
allocation  and  control  by  the  process  hierarchy  provides  a 
cle.   i   scha  li  .1  for  creating  user  operating  systems.   Evo- 
lutionary processes  permit  the  deferral  of  the  choice  of  a 
particular  network,  while  providing  a  clear  mechanism  for 

u  rating  it  and  for  making  adoptive  changes  to  an  existing 
definition.   The  fact  that  there  is  never  any  asynchronous 
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fighting  over  a  process  state  by  systems  or  subprocessors 
means  that  the  implemented  have  no  race  conflicts  to  re- 
solve.  The  process  must,  and  can,  resolve  its  own  problems 
locally  to  that  process.   Finally,  although  the  network  was 
designed  to  provide  mechanisms  for  the  control  of  poten- 
tially uncooperative  processes,  process  cooperation  can 
still  be  exploited.   Within  a  process  state  all  operations 
except  operations  on  accountable  objects,  are  considered 
cooperative  and  limited  only  by  the  operators  available  in 
the  subprocessors  being  used.   If  the  processes  wish  to  use 
normal  control-point  communication  to  interact  and  not 
invoke  the  AO  subprocessor,  they  may  do  so.   Objects  ex- 
changed in  this  way  are  not  subject  to  accountable  object 
guarantees  and  therefore  the  processes  use  of  them  is  pure- 
ly cooperative.   The  single  unique  aspect  of  cooperation 
which  is  not  permitted  between  disjoint  processes  is  shared 
space.   The  whole  structure  presented  here  would  be  great- 
ly complicated  and  lose  much  of  its  implementation  effi- 
ciency if  it  were  permitted.   The  implementation  would  be 
constrained  to  maintain  the  shared  space  in  the  same  physi- 
cal memory  and  map  the  processes  onto  it  with  the  inherent 
conflict  and  race  problems.   Processes  could  not  be  arbi- 
trarily moved.   By  simply  factoring  processes  into  disjoint 
address  space  such  problems  do  not  exist.   As  was  shown  in 
our  TENEX  model,  sufficient  generality  can  be  obtained  with- 
in one  process  state  to  model  the  whole  TENEX  system  includ- 
ing  the  shared  space. 
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APPENDIX  A 
CONSTRAINTS 

Postulated  Design  Constraints 

CI.   The  designed  network  must  consist  of  a  set  of  inter- 
acting bounded  programmable  digital  computer  systems 
with  well-defined  processes,  and  be  open  to  communica- 
tion  with  foreign  systems  having  undefined  processes. 

C2.   Responsibility  for  meeting  the  postulated  design 
constraints  and  design  decisions  must  be  fac- 
tored between  the  network,  implementation,  and 
process  designers. 

C3.   Each  designer  must  have     icient  authority  to  con- 
trol the  effects,  on  the  processes  running  in  the 
network,  of  the  interactions  for  which  that  designer 
has  been  delegated  responsibility. 

Ck.      Although  processes  must  be  permitted  to  delegate  to 
other  processes  their  authority  to  control  p:    ss 
interactions,  the  delegating  process  always  retains 
responsibility  for  that  interaction  and  the  author- 
ity to  control  the  process  to  which  it  was  delegated. 

C5.   The  network  definition  must  provide  for  modification 

of  its  definition.   The  design  must  provide  sufficient 
constraints  to  be  able  to  delegate  safely  to  process 
designers  all  modification  decisions  and  authority  to 
control  the  effects  of  such  decisions  on  the  processes. 
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Delegation  of  Authority  Constraint 

Dl.   Responsibility  for  each  Interaction  and  authority 
to  control  it  must  be  uniquely  assigned  to  the  same 
designer. 

D2.   Network  designers  are  responsible  for  ensuring  that 

the  network  is  self  protecting,  meets  the  constraints, 
and  is  formally  defined. 

D3.   The  implementation  designers  are  responsible  for  the 
design,  construction,  and  maintenance  of  an  optimal 
equivalent  system. 

M.   The  process  designers  are  responsible  for  all  virtual 
interprocess  interactions. 

D5.   If  an  implementation  designer  has  an  unsolvable  prob- 
lem due  to  boundedness  which  effects  the  processes 
in  the  network,  the  effect  on  the  process  state  structure 
must  be  well-defined  so  the  process  designers  can 
ameliorate  the  consequences. 

D6.   Network  designers  are  responsible  for  the  initial 
definition  of  the  network  and  implicitly  for  all 
evolutionary  paths.   Implementation  designers  are 
responsible  for  the  implementation  of  the  initial 
definition  and  for  any  potential  evolutionary  path. 
Process  designers  are  responsible  for  selecting 
which  evolutionary  paths  will  be  followed. 
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Process  Designer  Constraints 

PI,  Processes  must  be  arranged  in  a  tree  structure  defin- 
ing their  hierarchy  of  responsibility  over  descendant 
processes. 

P2.  A  unique  root  process  must  exist  representing  overall 
process  management. 

P3.   No  processor  race  conditions  can  be  permitted  to  effect 
the  process  state  transformation  during  that  transfor- 
mation, 

P*i.   Operators  available  to  process  designers  affect  only 
the  containing  process  state. 

P5.   Multiple  processes  may  be  transformed  in  parallel. 

P6.   Distribution  of  processes  over  the  network  must  be 
permitted  and  each  process  state  must  be  uniquely 
contained  in  at  most  one  system  at  a  time. 

P7„   Interprocess  communication  must  be  permitted  and  be 

subject  to  parental  control.   Synchronization  between 
processes  is  the  responsibility  of  process  designers. 
Processes  residing  in  different  systems  may  be  syn- 
chronized only  using  interprocess  communication. 

P8.   An  "accountable  object"  chain  must  exist,  and  processes 
must  be  able  to  restrict  use  of  these  accountable 
objects  when  sub-allocated. 
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Network  Designer  Constraints 

NI.   The  network  designer  is  responsible  for  providing  a 
set  of  invariant  names  which  can  be  used  by  the 
process  designers  for  communication  and  control. 

N2,   The  network  designers  are  responsible  for  changes 
in  the  network  formal  definition. 

N3.   Sufficient  services  must  be  provided  by  the  network 
designers  for  the  process  designers  to  accomplish 
their  purpose,  including  resource  accounting  and 
intersystem  communication. 

N4.   Network  modification  operators  are  meta-operators 

and  must  first  ensure  the  modification  does  not  vio- 
late any  of  the  postulated  constraints  and  then  either 
act  as  a  no-op  if  it  is  one  of  the  permissible  paths 
of  evolution  or  fault  if  it  is  not. 

W5.  The  effects  of  network  evolution,  other  than  the  ad- 
dition of  a  new  system  to  the  network,  must  be  local 
to  the  system  within  which  the  operator  was  executed. 

N6.   The  network  design  must  permit  process  designers  to 
limit  the  effects  of  a  network  modification  operator 
to  the  process  executing  it.   Process  designers  must 
be  able  to  uniquely  control  the  right  to  execute 
non-commuting  modification  operators  (if  any  exist). 
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APPENDIX  B 
DESIGN  DECISIONS 

Al  -  Each  system  processor  in  the  network  will  contain  a 
set  of  identifiable  subprccessor-s  including  at  least 
the  following  three:   GP  (General  Programmable),  AO 
(Accountable  Object),  PR  (Process  state  Receive  and 
transmit ) . 

A2  -  A  process  state  is  defined  by  a  set  of  identifiable, 
typed,  possibly  related  expression  states,  and  asso- 
ciated information  necessary  for  both  subprocessor 
allocation  and  interprocess  interactions. 

A2.1  -  Subprocessor  -access  to  structures  of  any 

other  type  of  expression- state  must  not  violate 
the  conventions  of  the  other  expression-state's 
designer. 

A3  -  "Control-Points"  are  accountable  objects. 

A3.1  -  Individual  control-points  may  be  paired 

with  individual  expression-states  and  more 
than  one  such  pair  may  exist  in  a  process 
state  at  one  tin 

A3. 2  -  When  paired  with  an  expression  state,  a 

control-point  will  have  associated  with  it 
the  type  of  3ubprocessor  to  be  applied. 
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A*J  -  Control-points  will  serve  as  uniquely  named  destination 
addresses  for  interprocess  messages.   The  arrival  of 
such  messages,  as  well  as  local  subprocessor  opera- 
tions, may  designate  an  ES/CP  pair  as  requesting  a  sub- 
processor,  regardless  of  the  status  of  other  pairs. 
The  system  processor  will  apply  at  most  one  subpro- 
cessor to  a  process  state  each  process  step. 

Aij.l  -  Each  process  state,  except  the  PR  process  state, 
will  contain  an  ES/CP  pair  which  can  interrupt 
all  others  in  that  process  and  which  can  be  in- 
terpreted by  the  AO  subprocessor. 

A^.2  -  In  addition  to  its  basic  functions  the  AO  sub- 
processor  will  be  responsible  for  regulating 
process  birth,  death,  and  intersystem  movement, 

A5  -  A  process  may  generate  a  single  interprocess  message 
each  process  step,  which  is  broadcast  by  the  system 
processor  to  a  particular  buffer  associated  with  the 
destination  control-point.  Process  designers  can  con- 
trol the  right  to  transmit,  the  right  to  listen,  and 
the  right  to  allow  an  ES/CP  pair  to  become  demanding 
as  a  result  of  a  buffered  message. 

A6  -  The  initial  network  definition  will  consist  of  one 

basic  system  with  an  initial  root  process  state.   Net- 
work modification  operators  will  permit  the  creation 
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of  at  least  additional  basic  systems,  subprocessors , 
subprccessor  operators,  and  system  processor  operators 
for  control-point  housekeeping. 

A6.1  -  The  design  of  modification  operators  will  be 

delegated  to  subprccessor  designers.  Modifica- 
tion operators  will  not  introduce  new  modifica- 
tion operators. 

A7  -  Inaccessible  objects  may  result  from  met a- ope rat ions 
invoked  by  implementation  designers  because  either  a 
subprocessor  hits  a  bound  or  there  is  an  implementation 
failure.     ^processors  trying  to  access  an  inaccessi- 
ble object  will  fault, 

A7.1  -  Implementation  failures  affecting  the  account- 
able object  chain  may  cause  ghost  processes. 
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APPENDIX  C 
EXAMPLE  FORMAL  NETWORK  DEFINITION 

INTRODUCTION 

This  appendix  will  formally  define  an  initial  basic 
system  and  also  define,  as  an  example,  a  two  system  network. 
The  definition  system  to  be  used  here  is  described  in  F3 
and  is  formally  defined  in  the  appendix  of  Jo73.   An  imple- 
mentation of  the  definition  system  exists  on  the  Universi 
of  Wisconsin's  UNIVAC  1108.   The  representation  used  in  the 
listing  of  the  definitions  presented  later  will  be  that 
accepted  by  the  implementation  in  order  to  avoid  "typographi 
cal"  errors. 

Although  familiarity  with  FH71  is  necessary  for  a 
precise  understanding  of  definition  details,  a  brief  intro- 
duction to  the  system  will  be  presented  here  so  the  reader 
who  is  not  familiar  with  it  will  have  a  reasonable  idea  of 
what  is  being  done.   The  definition  system  has  the  ability 
to  represent  a  set  of  interacting  asynchronous  digital  com- 
puter systems  as  extensions  of  Post  production  systems 
(FH71) .   The  automaton  which  interprets  the  definition  sys- 
tem defines  the  concepts  of  processor  and  process. 

As  in  Post's  formal  system  there  is  an  alphabet  (x) 
axioms  (a:)  and  productions  Or:).   Some  of  the  extensions 
to  the  Post  system  are  "not  x"  to  represent  any  single 
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character  except  xr  where  x  is  in  the  alphabet;  the  ability 
to  discard  irrelevant  axioms;  the  ability  of  one  system  (SR) 
to  communicate  with  another  system;  and  the  generalization 
of  antecedents  to  permit  the  use  of  restricted  processors 
(RPRs).   (RPR  is  described  in  FH'/l  and  (7)  is  an  example  of 
the  use  of  an  RPR  in  the  network  definition.   The  parenthe- 
sized numbers  correspond  to  the  parenthesized  numbers  found 
on  the  system  listings  and  are  used  to  indicate  specific 
items  which  will  be  discussed  here.) 

An  SR  (system)  has  the  property  that  it  runs  asyn- 
chronously with  all  other  SR*s.   Each  of  the  three  systems 
presented  in  the  network  definition  is  an  SR.  Messages  are 
transmitted  as  an  axiom  naming  a  destination  axiom  to  be 
matched  (in  the  destination  SR)  and  a  message  which  replaces 
that  axiom  in  the  destination  SR.   A  flowchart  describing 
the  primitive  automaton  is  found  in  fig.  4a,  b,  c.   It 
applies  the  operators  (productions  including  double  arrow 
productions  (9)  which  transmit  messages  and  restricted  pro- 
cessors (7)  to  the  axioms,  saving  only  generated  axioms,  up- 
dates the  axiom  set  with  any  incoming  message,  and  then  re- 
peats the  cycle.   A  system  step  is  defined  as  one  cycle  of 
the  primitive  automaton  as  described  above. 

An  RPR  can  be  a  part  of  the  left  hand  side  of  any 
operator.   The  main  difference  between  its  representation, 
and  that  of  a  system,  is  that  it  has  a  pattern,  in  place  of 
an  axiom  set,  which  must  be  matched  (using  the  RPR  alphabet) 
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before  the  RPR  is  applied.   RPR's  operate  only  on  the  pat- 
tern matched  substrings  of  axioms.   An  RPR  can  go  through 
many  cycles  itself  before  returning  to  the  containing  SR, 
thus  permitting  arbitrarily  complex  system  steps. 

The  flowchart  (fig.  4a,b,c),  symbol  descriptions r    and 
definitions  were  written  by  Pamela  Smith. 

SYMBOLS  (fig.  4) 

u       system  process  state  set, 

o '      buffer  to  hold  generated  process  states  during  the 
system  step  in  which  they  are  generated. 

a"  message-receiving  buffer. 

C(a")  a  consumable  copy  of  a". 

ir  the  set  of  productions  (operators)  in  the  system. 

C(vt)  a  consumable  copy  of  tt  . 

3       a  buffer  for  (channel,  message)  pairs  during  the 
system  step  in  which  they  are  generated. 

3      a  buffer  for  (channel,  message)  pairs  during  the 
application  of  the  production  from  which  they  are 
generated. 

3RPR    a  buffer  for  (channel,  message)  pairs  during  the 
execution  of  the  RPR  by  which  they  are  generated. 

x       a  buffer  for  RPR  results  which  are  generated  before 
the  RPR  terminates. 

P      a  production  selected  at  random  from  C  (tt  )  . 

S      an  element  selected  at  random  from  C(a");  it  is  a 
message  set,  consisting  of  a  unique  channel  name 
and  a  set  of  messages  associated  with  that  name. 

SR     a  Boolean  stack  variable,  true  if  an  SR  is  being 
executed,  false  if  an  RPR  is  being  executed. 

v       the  empty  set. 
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Fig.  4a-- INTERPRETER  Flowchart 
the  transformation  of  axioms 
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Fig.  M-b— INTERPRETER  Flowchart  (Cont.) 
terminal  Lou  of  an  RPR  application 
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Fig.  He— INTERPRETER  Flowchart  (Cont.) 
SR  process  step  termination  and  message  management 
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A      the  null  string. 

mark    a  designation  that  can  be  attached  to  a  process 
state,  then  erased;  it  means  that  no  production 
has  been  applied  to  this  process  state  since  the 
beginning  of  the  system  step. 

flag    a  designation  that  can  be  attached  to  a  process 
state,  then  erased;  it  means  that  this  process 
state  has  just  been  introduced  to  c    as  a  trans- 
mitted and  accepted  message. 


DEFINITIONS  (fig.  4) 

TRANSMIT  5  The  transmit  primitive  takes  the  (channel, 
message)  pairs  of  $  and  forms  them  into  message 
sets  before  sending.  There  is  a  conflict  reso- 
lution mechanism  which  enables  each  system's  o" 
to  be  able  to  determine  the  order  of  arrival  of 
the  messages  it  receives. 

SEIZE... FREE   A  primitive  that  takes  a"  out  of  commission 
without  loss  of  messages. 

MATCH   A  $    can  match  any  string  over  (x+A) *  in  any 
context. 

APPLY  P  TO  a        Finding  a  new  way  to  do  this  implies 
binding  of  the  variables. 

GENERATE  ALL  CONSEQUENTS   All  results  (states  that  match 
the  pattern  but  no  antecedents)  will  be  used,  no 
matter  when  they  were  generated.   A  result  of  A 
V7J.11  cause  the  RPR  pattern  $  to  become  A  in  the 
consequent.   No  consequents  will  be  generated  if 
the  result  is  <f> . 

STACK:  a,7T,T,e,3p/ff',C(Tr)  ,  P,  SR,X- 

DESCRIPTION  OF  NETWORK  DEFINITIONS 

In  the  next  section  three  systems  are  defined.   Sys- 
tem A  is  the  definition  of  an  initial  root  system,  and  sys- 
tems B  and  C  are  the  two  systems  in  a  two  system  network 
example.   The  implementation  accepts  an  arbitrarily  large 
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set  of  "characters"  in  the  form  of  alphanumeric  symbols 

(such  as  Alpha  or  B3  5) .   Each  such  symbol  is  treated  as  a 

single  character.   Alphanumeric  symbols  may  be  delimited  by 

any  character  (including  a  space)  except  a  letter  or  digit. 

Meta  characters :   The  following  meta  characters  are 

used  by  the  interpreter.   (Note  that  all  of  these  characters 

can  be  quoted  and  then  used  just  like  any  other  character 

in  the  system  definition.) 

[]   -   beginning  and  end  markers  for  an  SR  and  RPR. 

:    -   marks  the  beginning  of  the  axiom  set  {oj_)    of 
an  SR  (Note  RPRs  have  only  an  axiom  pattern) . 

#    -   marks  the  beginning  of  the  alphabet  (x : )  of 
an  SR  or  RPR. 

%    -   marks  the  beginning  of  the  productions 
(operators)  (tt:  )  of  an  SR  or  RPR. 

&    -   separator  between  axioms  in  the  axiom  set 
and  between  antecedents  in  a  multiple 
production. 

;    -   separator  between  productions. 

■*■    -   arrow  used  in  productions.   A  single  arrow 

separates  the  antecedents  and  the  consequent. 
In  a  double  arrow  production  the  second 
arrow  separates  the  consequent  message  from 
the  destination  name. 

\   -   "NOT"  (\a--matches  any  character  in  the 
alphabet  but  "a") . 

$    -   matches  any  string  over  the  alphabet  including 
the  null  string. 

<integer>  -  subscripts  for  variables  in  consequents 
which  name  variables  in  antecedents. 

Axiom  sets  (1) :   The  following  is  a  definition  of  the 

possible  state  sets  of  the  network  systems  (subject  to  the 
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addition  of  other  state  sets  of  the  netv/ork  as  the  result  of 

network  modification)* 

<system  state> : :-<system  phase>  <chan  list>  <buff  list? 

<process  list>  <candidate  list> 
<modify  list> 

phase-  each  system  has  a  phase  counter  (3)» 

<system  phase>: :=PHASE  <phase  number> 

<phase  nuraber> : :=1 | 2 | 3 

chan-  each  system  will  have  a  set  of  channels  to  receive 
messages  for  its  control-points, 

<chan  list>: :=<message  channel>| <message  channel> 
<chan  list> 

< message  channel> : :=&CHAN  < control-point  name> 

<buffer  namexmsg> 

<control-point  name>::=<AO  name> | <PR  name> | <GP  name> 

<A0  name> : :=<process  name>AO 

<process  name>: :=<root  name> j <process  name>. -cchild  name> 

<root  name> : :=1 

<child  name>: :=<integer> 

<integer>  :  :=<digit>  |  <nzeroxndigit> 

<ndigit> : :-<digit> | <digit>  <ndigit> 

<digit>: :=0 |<nzero> 

<nzero>::=l|2|3|4|5|6|7|S|9 

<PR  name> : :=<system  number>PR 

<system  number> : :~<integer> 

<CxYJ   name> :  :=<priority>GP 

<priority>:  :=<integer> 

<buff er  name> : :=<parent  buff er> | <intcrf ace  buff er> | 

<integer>|<acknowledge  buff er> 

<parent  bufferx :=P | <process  name> 

<interface  buff er> : :=R 

acknowledge  buff  er>  :  :=S 
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<msg>  :  :=<null>  j  A<message>  [  A<inaccessible  object> 

<null> i t- 

<message> : :=to  be  defined  by  subprocessor  designers 

<inaccessible  object>  i  :=# 

buff-each  system  will  have  a  set  of  control-point  buffers. 

<buff  list> : :=<message  buff er> | <message  buf f er> 
<buffer  list> 

<message  buff er> : :=&BUFF<control-point  namexbuff  name> 

<msg> 

process-each  system  will  have  a  set  of  processes 

<process  list> : :=<process> I <process><process  list> 

<process>  :  ;=&<interface>PROCESS<process  state> 

<interf ace> : :=<null> | <msg> 

<process  state>::=<PR  state> | <user  states 

<PR  state> : :=CP<system  number>PR&^demand>PR[<PR  exp- 
state> ] 

<demand> : :=0| 1 

<PR  expression-state>: :-<acknowledge  list> 

acknowledge   list>:  :  =  <ack>  |  cackxacknowledge  list> 

<ack>: :=<slist> ^process  name> 

<slist>: :=S1|S2 

<;user  state>  :  :=CP<process  name>AOA<demand>AO[  <A0  exp- 

state >] 

<A0   exp-state>:  :  =  <AO-ESxGP-ES   list> 

<AO-ES>::=to  be  defined  by  AO  subprocessor  designer 

<GP-ES   list>::r--null|^GP  ES/CP   pair>  |  <GP  ES/CP  pair> 
<GP-ES   list> 

<GP  ES/CP  pair>::  =  <GP   control-pointxGP-ES>  I  <GP-E3> 
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<GP-ES> : :=to  be  defined  by  the  GP  subprocessor  design- 
er 

<GP  control-point? : :=  CP<GP  namexCP  statusxarm  list? 

<CP  status? ; :=A<demand>A<enable?A<deliver  order> 

<enable>: :=0|1 

<deliver  order>::=0|l 

<arm  list?: :=<null?| <arm  status>|  <arm  statusxarm  list> 

<arm  status? ::=<status><GP  namexbuffer  name> 

< status > : :=ARM|DARM 

Candidate  list  only  exists  in  phase  1  and  tells  which  control- 
points-  are  candidates  to  have  a  subprocessor  applied. 

<candidate  list> : :-<null> I  <candidate> | <candidate> 

<candicate  list> 

<candidate>  :  :=&<can  statusxcontrol-point  name> 

< can  status > : : =CAN | NCAN 

Modify  list  is  the  list  of  modification  operations  to  be 
carried  out  (phase  3  only). 

<modify  list> :  :=<null>  |  <;modify>  |  <modify>  <Jnodify  list> 
<modify>  :  :=&f-10DIFY<process  namex;modxGP  name> 
<mod>::==NEW|KILL 

State  set  restrictions:   the  following  constraints 
will  hold  on  the  state  set  of  each  system  in  the  network. 

a)   The  system  will  contain  one  process  with  a 
<PPl  state>  with  the  proper  <;system  number? .   There  will  be 
one  <message  channel>  with  corresponding  identification  for 
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each  other  system  in  the  network  and  one  PR  acknowledge 
buf fer> . 

b)  The  system  will  contain  a  finite  number  of  pro- 
cesses with  <user  state>. 

c)  For  each  <A0  name> ,  one  <message  channel>  will 
exist  for  <parent  buffers  <interface  buffer>/  and  <acknow- 
ledge  buffer>  along  with  one  <message  channel>  (with  appro- 
priate identification)  for  each  of  that  processes'  children. 

d)  For  each  <CP  namexbuffer  name>  in  an  <arm  status> 
there  will  be  a  <message  channel>  with  the  corresponding 

<CP  namexbuffer  name>  . 

e)  For  each  <CP  namexbuffer  name>  in  an  <arm  status > 
there  will  be  one  <message  buffer>  with  the  corresponding 
<CP  namexbuffer  name> . 

f)  On  Phase  1  there  will  be  one  <candidate>  for  each 
<control-point  name>. 

We  would  consider  an  appropriate  path  of  evolution, 
as  a  result  of  modification  operator  execution,  any  system 
which  would  meet  these  constraints. 

System  processor  operators:   The  %  production  set  (3) 
of  each  system  defines  its  operators.   The  line  numbers  refer 
to  the  root  system  definition  as  a  specific  example. 

Lines  9-11  (3):  These  operators  maintain  the  phase 
counter  (Fig.  5). 
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Line  12:  Print  out  axiom  set  for  system  verification 
purposes »  This  operator  is  not  required  as  part  of  the  sys- 
tem processor  operation. 

Lines  13-26  (4):   GP  message  buffer  operations  are 
carried  out  during  all  three  phases  as  follows.   Line  13 
clears  all  GP  input  channels  at  each  phase.   Lines  24,  25 
remember  any  message  already  in  a  GP  buffer  (if  buffer  is 
still  armed),  if  no  new  message  has  arrived  on  the  corres- 
ponding input  channel.   Line  26  buffers  any  new  message  (if 
the  buffer  is  armed).   Note  that  the  productionsj  lines  24 
and  26 ,  cause  only  the  most  recent  message  to  be  buffered. 
Line  14  ensures  that  any  disarmed  buffer  is  empty  at  the 
end  of  phase  3,  the  other  productions  are  applied  in  each 
phase.   There  will  be  a  set  of  productions  similar  to  lines 
24-26  for  each  GP  buffer. 

Lines  16-23:   AO  and  PR  message  operations  are  dif- 
ferent in  phase  3  than  in  phase  1  and  phase  2.   Lines  17,  1&, 
22.  and  23  update  AO  buffers  in  phase  3,  and  line  19  updates 
the  PR  buffers  in  phase  3*   Line  16  remembers  AO  and  PR 
channel  messages  in  phase  2  and  phase  3»   No  buffers  are 
required  for  AO  or  PR  control-points  except  during  phase  1 
since  their  communication  is,  by  design,  cooperative.   There 
will  be  one  production  like  each  of  lines  22  and  23  for  each 
AO  in  the  system. 

Phase  1:   Designate  which  control-points  are  to  have 
subprocessors  applied  (Fig.  5)  (5).   The  control-point 
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Phase  1 

for  each  process  determine 

1)  which  subprocessor  to 

apply  based  on  priority  of 
control-points  which  are 
candidates, 

2)  put  messages  for  selected 
control-point  in  interface 
buffer  as  appropriate. 

3)  message  buffer  operations.! 


1)  dispatch  generated 
messages. 

2)  determine  which 
control-points  are 
candidates  to  have  a 
subprocessor  applied. 

3 )  message  buffer 
operations. 


1)  apply  subprocessor 
(process  step) 

2)  message  buffer 
operations-* 


Phase  3 


Phase  2 


Fig.  5  —  System  Phases:   the  system  processor 
has  a  cycle  of  three  system  steps  which  includes  one  process 
step  (phase  2). 


designated  within  each  process  will  be  indicated  by  a  " :" • 
A  process  which  has  no  control-points  which  are  to  have  a 
subprocessor  applied  will  be  marked  with  a  »••«  preceding 
its  state  (lines  32  and  i+S).   If  an  AO  is  demanding  (line 
27,  28)  it  automatically  gets  a  subprocessor  applied  since, 
by  design v  it  is  always  the  highest  priority  control-point 
in  a  process.   If  AO  has  been  designated  a  candidate  (done 
in  phase  3  as  a  result  of  being  demanding  or  having  a  pending 
message),  and  if  it  is  not  currently  demanding,  then  lines 
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33-35   designate  it  demanding,  place  all  buffered  messages 
in  the  interface  buffer  for  that  process >  and  mark  the  pro- 
cess (with  a  :)  to  have  a  subprocessor  applied.   Lines  36- 
46  determine  which  GP  control-point  (if  any)  should  have  a 
subprocessor  applied  if  the  AO  control-point  in  that  process 
is  not  a  candidate  (NCAN).   For  any  GP  control-point  to  be 
designated  to  receive  the  subprocessor,  it  must  be  "CAN" 9 
and  "NCAN"  must  hold  for  all  higher  priority  control-points 
in  that  process.   Then,  if  it  is  demanding  (lines  36,  37) ? 
designate  it  to  hove  a  subprocessor  applied  (no  messages  are 
delivered).   If  not  demanding,  place  either  single  (lines 
3&;    39)  or  multiple  (lines  42,  43)  messages  in  the  interface 
buffer,  and  designate  the  control-points  to  have  a  subpro- 
cessor applied.   Lines  40,  41  and  44»  45,  46  clear  the  buffers 
when  messages  are  put  into  the  interface  buffer. 

Lines  27-32  designate  PR  to  receive  a  subprocessor. 
During  phase  1,  PR  gets  all  pending  messages  put  in  its 
interface  buffer  (lines  29,  30)*   If  there  are  no  messages, 
and  it  is  demanding,  then  line  31  designates  it  to  have  a 
subprocessor  applied.   There  will  be  a  set  of  operations 
like  lines  33-47  for  each  process  (except  PR)  in  that  sys- 
tem, 

Subprocessors  are  applied  during  Phase  2(6) *   If  the 
process  was  marked  as  having  no  control-point  which  was 
to  have  a  subprocessor  applied,  then  the  mark  is  removed 
(line  48).   The  AO  subprocessor  (lines  £3-87)  and  GP  sub- 
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processor  (lines  £3-92)  are  not  part  of  this  design.   As  de- 
fined here  they  only  clear  the  interface  buffer  and  set  the 
control-point  not  demanding  (lines  85  and  90),  or  if  there 
is  no  message  in  r,he  interface  buffer,  they  set  the  control- 
point  not  demanding  (lines  £6  and  91)  • 

The  PR  subprocessor  (lines  51-32)  (7)  has  been  defined 
as  follows •   PR  may  get  multiple  messages  in  its  interface 
buffer  (S  is  used  as  a  message  separator).   Lines  54?  55 
execute  a  modification  operator  for  incoming  requests  to 
create  a  new  process  in  the  local  system.   The  modification 
request  tells  the  system  processor  which  control-points  a 
process  contains.   Line  $6  turns  off  the  demand  bit  (if 
there  is  no  message  in  the  interface  buffer  (!  Process) 
and  if  the  PR  expression-state  has  no  work  to  do  (•[Sl$])) 
and  removes  the  "!"  which  will  cause  the  subprocessor  to 
terminate.   Lines  55-5$  move  an  incoming  message  to  the 
expression-state  for  later  FIFO  service.   Line  59  clears 
the  null  messages  which  are  delivered  for  empty  buffers. 
Line  60-62  removes  one  local  request  (to  create  a  process) 
from  the  expression-state,  transforms  it,  and  places  it  in 
the  interface  buffer  as  a  "start"  request.   Lines  63-66 
send  back  to  a  source  system  an  acknowledgment  that  the 
process  state  arrived  correctly  and  marks  the  state  to  be 
started  the  next  time  the  PR  subprocessor  is  applied.   Lines 
67-69  start  such  a  process.   Lines  70-71  send  back  to  a  source 
system  over  the  acknowledgment  channel  that  an  inaccessible 
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object  (#)  arrived  in  place  of  the  process  state*   Lines 
72-74  do  not  transmit  another  process  state  since  there  is 
already  one  outstanding  (S1\A$9]).   Lines  75-78  transmit  a 
process  state  when  there  is  no  transmission  pending  acknow- 
ledgments.  Lines  $0,  Si  notify  the  proper  AO  by  an  "S"    if 
the  move  was  successful,  and  by  an  "R"  if  it  was  note   If  a 
PR  receives  a  returned  inaccessible  object  it  will  notify 
the  AO  control-point  that  initiated  the  move  that  the  re- 
quest failed.   If  a  PR  receives  a  process  state  it  will 
return  to  the  sending  PR  an  acknowledgment.   The  PR  origi- 
nally sending  the  process  state  will  notify  the  AO  which 
requested  the  move  that  it  succeeded.   That  AO  will  then 
kill  that  process  state  since  it  now  exists  in  the  other 
system.   This  procedure  guarantees  that  no  process  state 
will  be  logically  lost  during  intersystem  movement. 

Phase  3  (£)  dispatches  messages  and  designates 
potential  control-point  candidates  for  subprocessor  appli- 
cation.  Line  93  and  95  designate  a  demanding  AO  or  GP  as 
a  candidate  (CAN).   All  non-demanding  AO  and  GP  control- 
points  are  designated  not  candidates  (NCAN)  (lines  94  and 
97) •   NCAN  can  be  reset  (by  message  overwrite)  as  a  result 
of  a  message  on  a  channel  (line  102  and  104)  provided  the 
control-point  is  enabled  and  the  buffer  armed  (AO  is  always 
enabled  and  all  AO  buffers  arc  always  armed).   Messages 
generated  during  phase  2  which  are  for  local  control-points, 
also  reset  the  control-point  to  CAN  (line  109) •   The  candi- 
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date  mechanism  permits  us  to  know  in  advance  which  control- 
points  are  candidates  to  have  a  subprocessor  applied. 

Lines  106-137  do  message  dispatching. 

Lines  106  and  113  automatically  buffer  locally  any 
message  generated  for  a  local  CP  if  it  is  armed. 

Lines  111,  121,  124  dispatch  any  non-local  message. 

Line  113  kills  a  process  and  executes  appropriate 
modification  operations. 

Line  127  starts  a  process  (request  was  from  PR) . 

Line  130  buffers  a  move  request  for  PR. 

Lines  136,  137  create  empty  PR  buffers. 
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CS':GP$  ^PROCESS  ARM  OARM  P  R  S  AO  GP  *•     0  1 

TEST  CP  2  3  4  'C  ' 3  '    '  »  t 

%     "SPROCESSS'JGP'MS     ->     PK0CESSS<2>';GPM$O>     • 


<  1>S<M>' 3     1 


; 


PHASE 


PHASE     2     b 


a   i 


>     PR0CESS$<1>'  :GP~0  <»<2> 


(8) 


PHASE  3  >j 
PHASE  3  b 
PHASE  3  b 
->CAN 
PHASE  3  b 


,83A0*1$  -> 

.zaAO^us  -> 

,  2  3  A  0  S  C  P  C  \  *  tt  1 


CAN  s<2>A0  5 
N  C  A  N  5  <  2  >  A  0 


I 


'HAC  GP23S 


(9) 


PRCCESSS'  :gp~u 
->  5<1>GPS<2>  ; 
SPROCESS  CPCSMl  2 
SPROCESS  CPCSUl  2 

SPROCESS  CPCSttl  2  ,  2 3 AO $CPC \ *rt  1  2  3  'UIGP'MS 
\*<1>GP  ! 

SPROCESS  CPCS»1  2  ,Z3A0SCPC\~»1  2  3  *ii3GP'-0S 
-  >  NCAN  \"<1>  GP  i 
PHASE  3  b    "KOVESCPCSttl  2  3  M.8JC\ 

->  NCANS<2>\*<1>  i 
PHASE  3  ->  NCAN  I  PR  ! 

PHASE  3  b    CHANCShI  2  .«3C\GPUA0  PR23\~*S 

»>  CANS<|>\GP<1>  -  >  NCAN$<1>\GP<1>  } 

PHASE  3  b     C\*»CriAN  13UFFZ3  I  GP  1*5  b     SCP 

->  CAN  1  GP  ->  NCAN  1  GP  i 
PHASE  3  b    *CHAN  I  GP  l~SPROCESS$  b    :-CP  1 
b     CS^fCHANI  0  U  F  F  8  3  I  GP  IS 

-  >  BUFF  1  GP  1~S<!>  ->  HUFF  1  GP  1S<6>  ! 
PHASE  3  b     ~CHAN  1  GP  1~SPR0CE5S$  b     SCP  1  GP' 

~>  CAN  i  GP  ->  NCAN  1  GP  i 
PHASE  3  b     ~CHANC\~w2  3  4 2 3GP  \~S PROCESSS 

~>    CHAN\"<1>GP\*<2>S<1>    ->     CHAN\"><l>GP\-*<2>     5 
PHASE     3    b     KlLLCSB'C     '3     '        ARM     DAR'I     CP     F     R     S     AO     GP 


!     GPA0*1SAR,'1 
GP"0"lSARM     1 


GP     IS 
1$ 


OMSARM     1     GP     IS 
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114 
lis 

116 

1  17 
1  IB 

1  1? 
120 
121 
122 
123 
12H 
125 
126 
127 
128 
129 
130 
131 
132 
133 
13H 
135 
136 
137 
133 


0  1  2  3  H  ♦  « 
8SCPC\*\*»|  2  3  4  AO  GP8DS  -> 

M0DIFY\*<1>\*<2>KILL  ->  MODIFY  1  1 
3  ->  5 

PHASE  3  fc  •CHAUtiKl  2.»3AOsPkOCESSS  -  >  BUFFS<l>A0S<2>  { 
PHASE  3  b     SPR0CES5  CP  1  AO-Os  &     ~CHAN  1  AO  R$ 

->  CAN  1  AO  ->  NCAfJ  1  AO  i 
PHASE  3  fc  SPROCESS  CP  1  AO~lS  b     "CHAN  1  AO  RSPR0CE5SS 
0     CHAN  1  AO  R$ 

->     CHAN     1     AO     R$<5>5<3>     ->     CHAN     1     AO    R5<5>     1 
PHASE     3    fc     ~CHANC'SAO\'>ttl     2     3     H     . 

S  1  A0\*  ->  ,  AO  t  J 
3$PR0CESS5  -  >  CHANS<1>A0\*<1>S<2>  ->  CHANS<l>AO\*<l>} 
PHASE  3  6  "STARTiPROCESS  CP  l  PRS  ->  PR0C£SSS<1>  J 
PHASE  3  i,  *CHANC\*f<283PR\*'5P«0CESSS 

->CHAN\"<1>PKS"<2>$<1>  - >  CHAN\*<1>PR\*<2>  1 
PHASE  3  &     AMOVE\"CPCSttl  2  .23A0S 

->  BUFF  1  PRS<1>~0  MOVL\"< 1 >CPS<l>A0i<2>  ; 
PHASE  3  6  ~MOVE\~S  ->  PROCESS  3<1>  ! 
PHASE  3  &  *C\*«MOVE  NE»S3S  ->  CAN  1  PR  ->  NCAN  I  PR  { 
PHASE  3  0     "'NE  A  SPROCESS  C  P  C  S  «  1  2  .  Z  3  A  0  S  -  >  BUFF  1  P  R  $  <  2  > 

"0    NEW  Q5<2>  ; 
PHASE  J  i,     "CHAN  SPROCESS  CPLSul  2  .  Z  3  A  0  $  -  >  BUFF  t  P  R  S  <  2  >  ~  ', 
PHASE  3  6  PROCESS  CPC$«1  2  tiDAOS  ->*  BUFF  1  PR5<1>  I 
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SYSTEM  B 

1  (1)  c:  PHASE  3  b     CHAN  1  AO  P  b    CHAN  I  AO  R 

2  &  CHAN  I  AO  1  t  CHAN  1  AO  2 

3  fr  CHAN  I  AO  S  (  CHAN  I  PR  S 
H  &  CHAN  1  PR  2 

5  b    CHAN  1  GP  1  b    BUFF  1  GP  1 

6  t  CHAN  I  GP  2  &  BUFF  1  6P  2 

7  &CHAN1GP3&BUFF1GPJ 

8  6  MODIFY  1 

9  t  PROCESS  CP  I  PR*1  PR'CSI'] 

10  b     PROCESS  CP  1  A  0  "  0  AO'C  '  CP  1  G  P  A  0  A  1  A  U  OARM 

11  1  dP  I  DARN  1  GP  2  DARN  |  GP  3  GP'C']'] 

12  (2)   ii  PHASE  0  12  3  4  CHAN  BUFF  PROCESS  ARM  DARM  CAN 

13  NCAN   MC01FY  KILL  PR  AO  GP  C P  P  R  S  *  ' C  ' 3  »   ';  J  , 
1 H  MOVE  START  NEW  TEST  ♦»  Si  S2 

15  (3)   a  PHASE  1  ->  PHASE  2  1 

16  PHASE  2  ->  PHASE  3  I 

17  PHASE  3  ->     PHASE  1  ! 

18  S  ■>  S  SI'  '  $<1>  •>  PRINT  I  I 

1?   (1+)  CHA(,\~GP\AS  ->  CHAN\~<1>GP\A<2>  1 

20  PHASE  J  b     SPROCESS  C  P  C  S  «  1  2  .  S  3  A  0  $DARM\"\A\"S 

21  ->  BUFr \-< 1 >\~<2>\A<3>  ! 

22  PHASE  \  3  b     C  H  A  N  C  $  »  1  2#23C\GPtiA0  P  R  3  3  $  -  >  CHAN$<1>\GP<1>$<2>  { 

23  PHASE  3  b     SPROCESS  CP  1  A  0  A  1  s  b     CHAN  1  A  0  $  ->  CHAN  1  A0$<3>  I 

24  PHASE  3  b     AMOVE\~Cp  1  AOi  b     CHAN  !  AO  S 

25  •>  CHAN  1  A0$<2>  I 

26  PHASE  3  (.     CHAN\APR\AAS  ->  B  U  F  F  \  A<  1  >PR  \  A<  2  >A\A<  2>5  <  1  >  { 

27  PHASE  3  b    CHAN\APR\A  ->  BUFF  \A<  1  >P(x  \  A<2>~  i 

28  PHASE  3  b     CHAN  \*  PRV'S  ->  ChAN  \A<1>  PR\A<2>  5 

29  PHASE  3  b    SPROCESS  CP  1  AO"Oi  b    CHAN  1  AOS  ->  bUFF  1  A0$<3>  J 

30  PHASE  3  b     SPROCESS  CP  1  AO'Dl  6  CHAN  1  A0\*5  ->  CHAN  1  A0\*<1> 

31  CHAN  1  GP  !  b     BUFF  1  GP  15  £-  SPROCESSSARM  1  GP  1$ 

32  ->  bUFF  1  GP  1$<1>  I 

33  CHAN  1  GP  2  £.  BUFF  1  GP  2$  b     SPROCESSSARM  1  Gp  25 

3  4  •>  BUFF  I  GP  2S<1>  I 

35  CHAN  1  GP  3  b     BUFF  1  GP  3$  6  SPROCESSSARM  1  GP  3$ 

36  ->  BUFF  1  GP  3S<1>  J 

37  CHAN  1  GP  l~i>  b     SPROCESSSARM  1  GP  1  i  -  >  d  J  F  F  1  GP  I  *  S  <  1  >  { 

38  CHAN  J  GP  2*$  b     SPROCESSSARM  1  GP  2S  ->  BUFF  1  GP  2AS<1>  5 

39  CHAN  I  GP  3  A  S  b     SPROCESSSARM  1  GP  3*  ->  BUFF  1  GP  3  A  S  <  1  >  1 

40  (5)  PHASE  1  b     PROCESS  CPCSWl  2  ,'A3A0*1S 

4  1  -  >  PROCESS  CPS<1>':a0~1s<2>  5 

42  CAN  |  PR  b     PROCESS  CP  l  PR"\*S  b     BUFF  l  PR  1*$ 

43  b     BUFF  1  PR  2"J  6  BUFT  I  PR  SAS 

44  ->  JS<2>fS<3>.»S<4>!PR0CES5  C  F  1  '  5  P  R  A  1  S  <  I  >  ! 

4  5  NCAN  i  PR  b     PROCESS  CP  1  PR-Ms  ">  fPROCESS  CP  1  ♦  :  P  R  "  1  IS  <  1  >  i 

46  NCAN  l  PR  t-  PROCESS  CP  1  PRA3s  ->  'IPROCESS  CP  1  PRAOi<l>  1 

47  CAN  i  AO  b     PROCESS  CP  1  AO~Oi  &  BUFF  1  AO  P5 

48  t  flUFf  !  AO  RS  i  EUH-'  I  AO  S5 

49  b     BUFF  1  AO  15  b     BUFF  1  AO  2% 

50  ->  S<2>S<3>S<4>S<5>$<6>PK0CESS  CP  1  *  I  A 0 » 1 S < 1 >  i 

51  NCAN  ■  AO  6  CAN  1  GP  &  SCP  I  GP"1S 

5  2  ->$<1>CP1':GPA1$<2>; 

53  NCAN  1  AO  b    CAN  1  GP  b    SCP  1  GPAaAlAOS 

54  b    BUFF  1  GP  I  A  S  -  >  AS<J>S<1>CP  1':gP~1a1*0$<2>  I 

55  NCAN  1  AO  b    CAN  l  GP  b    SCP  1  GP'O'TOS  b    CHAN  1  GP  IS 

56  &  BUFF  I  GP  1AS  ->  BUFF  1  GP  1S<3>  ->  BUrF  1  GP  1AS<4>  J 
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57 
58 
5? 

60 
61 
62 
63 
64 
65 
66 
67 
63 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

10H 

105 

106 

107 

108 

109 

1  10 

t  1  1 

1  12 

1  13 


•0-1*0$ 


(6) 


(7) 


SCP  t  GP 
1  GP  2"S 
•1M~0$<2>  I 
SCP  1  GP^O^l^OS 
1  GP  2*5  &    CriAN  1 
BUFF  l  GP  2  ~S<3> 
SCP  1  GP*,0*1*'0S 
I  GP  2  t  BUFF  1  GP 


GP  2S 


3*S 


NCAN  1  AO  (,     CAN  1  GP  C 

6  BUFF  1  GP  1  £,  BUFF 

->  -S<3>S< 1 >CP  1  '  :  GP 

NCAN  1  AO  6  CAN  1  GP  (, 

(,     3UFF  1  GP  1  &  BUFF 

->BUFF  1  GP  2S<4>  -> 

NCAN  1  AO  (,     CAN  I  GP  b 

b     BUFF  1  GP  1  £»  BUFF 

->  AS<3>$<1  >CP  t  *  :  GP-*  1  *  1  *0S<2>  \ 

NCAN  1  AO  fc  CAN  1  GP  6  SCP  1  G P*0* 1 "0 S 

(,     BUFF  1  GP  1  6  BUFF  1  GP  2  6  CHAN  1  GP  3S 
6BuFF  1  Gp  3~s  ->  BUFF  1  GP  3S<3>  ->  BUFF  1  GP  3A$<4> 
NCAN  1  AO  (,     CAN  I  GP  6  SCP  1  GP'-Q'M'MS 

t  BUFF  1  GP  IS  &  bUFF  1  GP  2S  6  BUFF  1  GP  3S 
->$<3>S<4>$<S>$<1>CP  1':GP*1A1~15<2>  » 
NCAN  I  AO  6  CAN  1  GP  6  SCP  1  G  P  ~  C  *M  ~1  $  6  CHAN  1  GP  1$ 
£•  BUFF  1  GP  1$ 

->  BUFF  1  GP  1$<3>  ->  BUFF  1  GP  IS<4> 
1  AO  6  CAN  1  GP  o     SCP  1  GP^O^l^lS 
HAN  I  GP  2S  L     BUFF  1  GP  2$ 
BUFF  1  r,p     2     S<3>  ->  HUFF  I  GP  2S<4>  { 
1  AO  £,  CAN  1  GP  6  SCP  I  GP- 0*1-1$ 
CHAN  t  GP  3S  6  BUFF  1  GP  3S 
BUFF  1  GP  3$<3>  ->  bUFF  1  GP  3*<4>  { 
1  AO  i,     NCAN  1  GP  &  PROCESS  CP  1  AOS  -> 
•£     2  (,     'IPROCESSS  ->  PRuCLSS$<1>  ', 
£  3  i,    SPROCESSS  ->  PR0CESS5<2>  ! 
E  2  ->  MOD  IF Y  1  I 
E  2  (,    CS':PRs«PROCESS  ARM  OARM  CP  P  R  S  PR  AO 


: 


NCAN 
fcC 
-> 

NCAN 
& 
-> 

N  C  A  N 
PHA5 
PHAS 

PHA5 

PHAS 


PROCESS  CP  \     aos<i>; 


START  MOVE  u£rt  TEST 


GP    -    0 
i     CHAN 


1     2     3     4     '  C     '  3 

' tt   ' :    si    S2 

SJ\*NElfi\*CPCSKl     2.B3A0?,CPC\'*»1     2    3    4  3  3  G  P  S  '  :  $ 

•>     M0DIFY$<l>Nt.'<\-<3>GP     ->     MODIFY     1      J 
JPROCESSSPR-1     PR'CSIS     ->     PROCESSS<t>PR-0     PR'LS1S<2>     { 
5LSASBARM     DARM     CP     P     R     S     AO     GP     -    U     1     2     3     4     'C     ' 3     .     ' ,t     SI     S2 
♦        TEST     MOVE     NE-VS3  f  $'  :  SSI  S     ->     J  S  <2>  '  '.  $<  3>\*<  I  >  ->  fl  >  <  S  1  $<  4  > 

l  f  s ' t  s  ->  ;$<i>':s<2>  ; 

JPROCESSSPR'CO  NEW  0  E  5.  «  A  R  M  DARM  CP  P  R  S  AO  GP  CP  PR  -  , 
I)  1  2  3  4  '  C  '  3  '    TEST  MOVE  NE/<  '«  Si  S2 
2  3  !  S  -  >  -STAKTS<2>PR0CESS$<1>PR'C$<3>  ,' 
.'PROCESS*  PH't\0  NEW \OCS BARM  DARM  CP  P  R  S 
AO  Gf-  -  U  1  2  3  4  'C  '  3  '    t23f  S 
-  >  -CHAN\(,<1>PR  S-R  PROCESS  S<1> 
PR'CSTARTs<2>fS<3>  I 
|PROCESS$PR'CSTARTC$«ARM  OARM  CP  P  R  S  AO  GP  - 
0  1234'C'J'    .  S  I  S  2  S  3  .'  S 
->-STARTs<2>PR0CESSS<l>P;<'C$<3>  i 
|PR0CE5S$lR'C\"'rtfS 

->  -CHAN\-<1>PR  S-S  PR0CESS$<1>PR'CS<2>{ 
fPROCESSSPR'CO  MOVE\OCS»Ar(M  DARM  CP  P  R     S 
AO  GP  *  0  1  2  3  't  '  C  '3  '    .S3fSSl\"*'3 
->PR0CESr!S<l>PR'CS<3>0  MO  V  E  \0<  1  >S<2>  J  S  1  \-<  1  >$<  4>  •  3  I 
•PROCESSSPR'CU  MOVF\OCPCS»1  2  t  Z  3  A  0  l  S 

ttAKrOARMCPPRSAOGP-Oi  23  4 
'  C  'J  '   .  %  3  !  S  S  1  '  :, 
•>*CHAN\Q<l>PR  lAt]L'.'l  1  CF$<2>A0S<3> 
PR0CES53<l>PR'CS<4>Sl$<2>'3  ( 
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114 
115 
1  l& 
1  17 
1  18 
I  19 
120 
121 
122 
123 
124 
125 
126 
127 
12S 
129 
130 
131 
132 
133 
134 
135 
136 
137 
130 
139 
140 
141 
1  '4  2 
143 
141 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 
155 
156 
167 
158 
159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
169 
170 


(8) 


(9) 


!PKOCESSSPR'CSC\*iiR  SSDfSSH'3 

->~CHAN5<3>A0  R~\-<l>PKOCESS$<l>PR' C$<2>S1 ' J  1 
3  ->  S< 1 >PR$<2>  ! 
PHASE  2  6  CS' : AOIKPROCESS  ARM  DARM  P  R  S  CP  AO  GP  *  0  1 
234'C'3'    ':'».  TEST 
ii*SPROCESS  CPCSal  2  ,2D':A0"1S  ->  PROCESS  CPS <2> '  • AC t $<3>  J 
PROCESS  CPCSttl  2  .43'JA0-1S  ->  PROCESS  CPS< 1 > '  I  AO-OS <2>  1 
3  ->  $<1>A0?<2>  I 
PHASE  2  6  CS'JGPS  bPROCESS  ARM  DARM  P  R  S  AO  GP  *  0  1 
TEST  CP  2  3  4  ' C  ' 3  •    '  t*     • 

a   -$processs':gpm$   ->   processs<2>*:gp*1s<3>    ; 

PROCESS*'  :6P~lS  ->  PP0CESS$<1>'  :GP~Qi<2>  ; 

->  5<1>GP$<2>  ; 

SPROCESS  CPCSM1  2  .83A0~lS  ->  CAN  $<2>A0  5 

SPROCESS  CPCSsl  2  ,»3A0"0S  ->  NCAN  $<2>  AO  J 

SPROCESS     CPCStU     2     .  2  3  AO  sCPC  \*  tt  I     2     3     4fcJGP*lS 

\*<1>GP     ! 

SPROCESS  CPCSW1  2  .%  ]AO$CPC\*i*  I  2  3  4S3GPAUS 

N  \  *  <  1  >  G  P  ; 

"MOVESCPCSw  1     2     3     4.23C\AKA0     GPS3S 

<2>\-><l>     i 

NCAN  1  PR  J 
CHANCSsl  2  .Z3C\GPBA0  PRSJ\**S 
S  <  1  >  \  G  P  <  1  >  ->  NCANS<1>\GP<1>  5 

C\"»CHAN  B  U  F  F  2  3  1  GP  1*5  i,     SCP  I  GP"U*15A"N  I  GP  IS 
Art  1  GP  ->  NCAN  1  GP   ! 
CVtlCHAN  B  U  F  F  a  3  1  GP  2  *  S  6  SCP  1  G  P  "  0  *  1  3  A  R  M  1  GP  2  5 

GP  ->  NCAN  1  GP  I 
C\*mCHAN  B  U  F  F  3  31  GP  3*5  6  SCP  1  GP^msARM  1  GP  3S 

GP  ->  NCAN  1  GP  ! 
*CHAN  1  GP  i-SPROCESSS  6  SCP  1  GP  ~Q*  1 S  ARrl  1  GP  1$ 

A  TJ  B  U  F  F  2  3  1  GP  IS 

t  GP  1~S<1>  ->  BUFF  I  GP  1S<6>  ! 

CHAN  1  GP  2*$PR0CE5Si  6  SCP  1  GPA0*  1  S ARM  I  GP  25 

N  B  U  F  F  2  3  1  GP  25 
GP  2  *  $  <  1  >  ->  BUFF  1  GP  2S<6>  J 

CHAN  1  GP3*SPR0CES5$  &  SCP  i  GP*0*1SAHM  1  GP  3S 

N     BUFF2JI     GP     35 
r,.°     3  *  5  <  1  >     ->     DUFF     1     GP     3  S  <  6  >     i 
*  C  H  A  N     1     GP     1*SPR0CESS$     &     SCP     1     GP*U'MSARM     1     GP     |S 
AN     1     GP     ->     NCAN     I     (,P      i 
*CHAN     1     GP     2A3PR0CLSSS    6     SCP     1     &P*0»lSARM     I     GP     2$ 

GP     ->     NCAN     1     GP     ! 
"CHAN     1     GP     2*iPR0CESS$     &     SCP     I     GP*OMSARM     1     GP     35 

GP     ->     NCAN     1     GP     J 
"CHANC\*H2     3     'U3GP\AS.oR0CES5S 
AN\»<1>GP\*<2>»<1>    ->    CHAN\*<l>SP\*<2>     5 
KILLCSM'C     '3     '        A  R ,-,    DARM    CP    P    R     S     AO    GP    "     , 
U     1     2     3     H     '  « 
BSCPC^N^nl     2     3     4     AO    GP23S    -> 

M0DlFY\*<i>\*<2>KILL    ->     MODIFY     1      1 

3  ->   ; 

PHASE  3  t,     *CHANCS»1  2.Z3AOSPKOCESSS  ->  BUFFS<1>A0$<2>  \ 
PHASE  3  L    SPROCESS  CP  1  AO"OS  6  "CrlAN  1  AO  R5 

->  CAN  1  AO  ->  NCAN  I  AO  i 
PHASE  3  6  1.PR0CESS  CP  1  AO-lS  6  *CHAM  1  AO  R5PK0CES3S 

0     CHAN  1  AO  R$ 


PHASE 
PHASE 
PHASE 

-> 
PHASE 

-> 
PHASE 

->  N 
PHASE 
PHASE 

-> 
PHASE 

PHASE 

->  C 
PHASE 

->  C 

PHASE 

6  r. 

-> 

PHASE 

0    C\ 

->   a 

PHASE 
6  C\ 
->  B 

PHASE 

FHASt. 

->  C 
PHASE 

->  C 

PHASE 

PHASE 


3 
3  0 
3  6 
3  6 
CAN 
3  6 

NCA 
3  i, 
CANS 
3  -> 
3  i, 

CAN 
3  (. 
->  C 
3  6 
AN  1 
3  i, 
AN  I 
3  I 
\*»C 

buff 

3  I- 

AttCH 

UFF 

*«CH 
UFF 
3  6 
->  C 

3  ;, 

AN  1 
3  6 
AN  I 
3  I, 
>     CM 
3  6 
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171 
172 

173 

17H 
175 
176 
177 
178 
17? 
160 
181 
182 
183 

1  a*4 

185 
186 
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SYSTEM  C 


1  (1)   cj  phase  3  fc  Chan  i.i  ao  i  &  Chan  l.t  ao  r 

2  &  CHAN  1*2  A  0  1  &  CHAN  1.2  AO  R 

3  I,  CHAN  1,1  AO  S  &  CHAN  1,2  AO  S 
6  CHAN  2  PR  S  (,  CHAN  2  PR  I 
(,  CHAN  2  GP  I  (,  BUFF  2  GP  1 
6  CHAN  2  GP  2  6  BUFF  2  GP  2 
b  CHAN  2  GP  3  6  BUFF  2  GP  3 
&  CHAN  3  GP  1  fe  BUFF  3  GP  I 
6  CHAN  3  GP  2  t  BUFF  3  GP  2 

c   Chan  m  gp  i  t,   buff  ' 

&  CHAN  H     GP  2  &  BUFF 
MnniFv  7 


5 
6 
7 
0 
? 

10  t  Chan  h    gp  i  &  buff  4  gp  i 

1 1  &  CHAN  4  GP  2  6  BUFF  4  GP  2 
12 
13 
11 
15 
16 
17 
18 
19 
20 
22 
22 
2 
2 
2 
2 


(,     MODIFY  2 

6  PROCESS  CP  2  PR-M  PR'CSl'j 

0    PROCESS  CP  1.1  A0*0  AU'C  CP  2  GP-O^l^l 

DARM  2  GP  1  DARM  2  GP  2  DART  2  GP  3  GP'C'3'3 

6  PROCESS  CP  1,2  AO-U  AO'CCP  H     GP  *0~1~1  DARM 
M  GP  1  DARM  <4  GP  2  G  P '  C '  3  CP  3  GP  ~  0  ->  1  ~  1  DARM  3  GP  1 

DARM  3  GP  2  GP'C  3'  3 
nHASE  0  1  2  3  <4  CHAN  BUFF  PROCESS  ARM  DARM  CAN 

ICAN   MODIFY  KILL  PR  AO  GP  CP  P  R  S  *  'C  '3  '    'J   J 

I  0  V  E  START  NEW  TEST  '  i»  Si  52 

HASE  1  ->  PHASE  2  t 


S  <  2  >  I 
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57 

58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
63 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
SO 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 
93 
94 
95 
96 
97 
9S 
99 
100 
101 
102 
103 

101 
105 
106 
107 
108 
109 
1  10 
1  1  1 
1  12 
1  13 


(5) 


GP 
J 

SPROCESSSARM 
SPROCESSSARM 
SPROCESSSARM 
SPROCESSSARM 
SPROCESSSARM 
SPROCESSSARM 
SPROCESSSARM 


SPROCESSSARM 
SPROCESSSARM 
SPROCESSSARM 


H  GP 
4  GP 


CHAN  3  GP  2  6  BUFF  3  GP  2$  6  SPROCESSSARM  3  GP  2S 

->  BUFF  3  GP  2$<1>  i 
CHAN  4  GP  1  (,     BUFF  4  GP  IS  fc 

->  oUFF  4  GP  1$<1>  i 
CHAN  4  GP  2  (,     BUFF  4  GP  2$  0 

->  BUFF  4  GP  2S<  1  > 
CHAN  2  GP  1  -  S  fc 
CHAN  2  GP  2*S  i, 
CHAN  I    GP  3*S  (, 
CHAN  3  GP  1*5  U 
CHAN  3  GP  2*5  t. 
CHAN  4  GP  l*S  b 
CHAN  4  GP  2*S  0 
PHASE  1  6  PROCESS  CPCS«1  2 
->  PROCESS  C  P  S  < 1 > '  :  A  0 
CAN  2  PR  t>    PROCESS  CP  2  PR 

I-    BUFF  2  PR  S*S 

6  BUFF  2  PR  1.1~S  &  BUFF  2  PR  1.2"$ 

->  !S<2>!S<3>fS<H>.'S<S>fPR0CESS  CP  2  '  5  P  R  *  1  $  <  1  >  I 


2 
2 
2 
3 

3 
4 
4 

.alAO 

1S<2> 


IS 
2i 
3S 
IS 
2S 
IS 
2S 

1$ 

! 


-> 

-> 
-> 
-> 
-> 
-> 
-> 


BUFF 
BUFF 
BUFF 
BUFF 
BUFF 
BUFF 
BUFF 


IS 

2S 

GP 
GP 
GP 
GP 
GP 
GP 
GP 


1AS<1> 
2*S<1> 
3*s<  t> 

1  *  %  <  1  > 
2"S<J> 
l*s<l> 
2-*s<l> 


•\"%       (,    BUFF  2  PR  1*S 


NCAN 

NCAN 

CAN 

f, 

CAN 
6 

NCAN 

NCAN 

NCAN 


2  PR  6 
2  PR  & 
1  .  I  AO 
HUFF  1 
6  BUFF 
1  .2  AO 


PROCESS  CP  2 
PROCESS  CP  2 

0  PROCESS  CP 

1  A  0  S 

1.1  AO  RS  -> 
i,    PROCESS  CP 


PR-MS  ->  .'PROCESS  CF  2  ' 
PR-OS.  ->  '  JPROCESS  CP  2 
1.1  AO-OS  6  BUFF  |  t I  AO 


;  PR-M  $<  1  > 
PR">0S<1>  t 
IS 


S<2>S<3>S<4>PR0CESS  CP  1 . I ' : AO* 1 S< 1 >  J 
1.2  AO-OS  <,     BUFF  1.2  AO  1$ 
QUFF  1.2  AO  SS 

6  BUFF  1.2  AO  R$  -  >  S<2>S<3>S<4>PR0CE5S  CP  1.2':A0"1$<V>  1 
1.1  AO  6  CAN  2  6P  6  SCP  2  G  P  *  I  S 

->  $<1>CP  2' IGP-l S<2>  ; 
1.1  AO  6  CAN  2  GP  b     SCP  2  GP*U*1A0S 
6  BUFF  2  GP  1*$  ->  -i<3>S<l>CP  2';GP*l*i"0S<2>  { 
.1  AO  (,     CAN  2  GP  6  SCP  2  GP*rj»l*Q$  6  CHAN  2  GP  IS 
BUFF  2  GP  1*$  ->  BUFF  2  GP  1S<3>  ->  BUFF  2  GP  1*S<4>  J 


(, 

NCAN  1.1  AO  (,  CAN  2  GP 
6  BUFF  2  GP  1  6  BUFF 
->  *S<3>$< 1 >CP  2' ! GP' 

NCAN  1.1  AO  fc  CAN  2  GP 
6  BUFF  2  GP  1  &  CHAN 


&  SCP  2  GP*OM~U$ 
2  G  P  2  *  $ 

i*l*os<2>    ; 

&  SCP  2  GP*0"1*0$ 
2  GP  2S  6  BUFF  2  GP 


2*S 


->  OUFF  2  GP 
NCAN  1.1  AO  (,     CAN 

6  BUFF  2  GP  1  6 

->-*$<3>S<l>CP  2 
NCAN  1.1  AO  i,     CAN 

<,  BUFF  2  GP  1  f, 

&  CHAN  2  GP  3S 

->  BUFF  2  OP  3S<3>  ->  BUFF 
NCAN  1.1  AO  o     CAN  2  GP  6  SCP 

&  BUFF  2  GP  IS  6  BUFF  2  GP 


2$<3>  ->  BUFF  2  GP  2~S<4>  j 
2  GP  t  SCP  2  GP*0"l*OS 
BUFF  2  GP  2  &  BUFF  2  GP 
'  : GP-1 *  1 ~0s<2>  i 
2  &P  t  SCP  2  GP-O-l'-OS 
BUFF  2  GP  2 
BUFF  2  GP  3*$ 


3*S 


2  GP  3~S<4> 
2  GP~OM*lS 
2S    6    BUFF     2 


GP 


->  S<3>$<4>$<5>'5<1>CP  7'IGP 
NCAN  1.1  AO  &  CAN  2  GP  6  SCP  2  GP 
6  BUFF  2  GP  IS 
->  BUFF  2  GP  1$<3> 
NCAN  1.1  AO  f,     CAN  2  GP  & 
&CHAN  2  GP  21  (,     BUFF  2 
">  3UFF  2  GP  2S<3>  -> 


1  *  1  *  1  5  <  2  > 
>U*1  "IS  & 


3S 

1 
CHAN 


2  GP  IS 


->  BUFF  2  GP  I  5  <  4  > 
SCP  2  GP*U-*1*I$ 

GP  2$ 
BUFF  2  GP  2S<4>  } 


NCAN  I  .  1 
( ,     CHAN 


2     GP 


CAN 
3S  i 


2  GP  6  SCP 
BUFF  2  GP 


2  GP-U- 
3S 


1*15 
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1  14 

1  15 
1  16 
I  !7 
118 
1  1? 
120 
121 
122 
123 
124 
125 
126 
127 
128 
12? 
130 
131 
132 
133 

131 
135 
136 
137 

138 
139 
140 
14  1 
142 
143 
144 
115 
146 
147 
148 
149 
150 
151 
152 
153 
151 
155 
156 
157 
158 
159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
169 
170 


(6) 


->  BUFF  2  GP  3S<3>  ->  BUFF  2  GP  3S<4>  J 
NCAN  1*1  AO  fc  NCAN  2  GP  fc  PROCESS  CP  1.1  AOS 

->  '  !  P  K  0  C  E  S  S  CP  1.1  A  0  $  <  I  >  S 
NCAN  1.2  AO  fc  CAN  3  GP  6  SCP  3  GP"1$ 

->  S< 1>CP  3  '  1GP"  1$<2>  1 
NCAN  1.2  AO  fc  CAN  3  GP  fc  SCP  3  GP^O^l^QS 

fc  BUFF  3  GP  1~$ 

->  *$<3>$<1>CP  3'  :GPM*1  *0s<2>  I 
NCAN  1.2  AC  fc  CAN  3  GP  fc  $CP  3  GP-O^l^OS 

fc  CHAN  3  GP  1$  fc  BUFF  3  GP  1"$ 

->  BUFF  3  GP  1»<3>  ->  UVFF     3  GP  1*5<4>  J 
NCAN  1.2  AO  £  CAN  3  GP  fc  SCP  3  GP*0~l*OS 

fc  BUFF  3  GP  |  fc  BUFF  3  GP  2*S 

->  *S<3>S<1>CP  3'  :gpm  M*0S<2>  I 
NCAN  1,2  AO  fc  CAN  3  GP  fc  SCP  3  GP-QM-OS 

fc  BUFF  3  GP  1  fc  CHAN  3  GP  2  $  fc  BUFF  3  GP  2*5 

->  BUFF  3  GP  2i<3>  ->  BUFF  3  GP  2*,S<4>  I 
NCAN  1.2  AO  fc  CAN  3  GP  6  SCP  3  GP~U~1*1$ 

6  BuFF  3  GP  IS  6  BUFF  3  GP  2S 

->  S<3>S<4>s<  1  >CP  3  '  !  GP*  1  "  1  *  1 S<2>  ; 
NCAN  1.2  AO  fc  CAN  3  GP  fc  SCP  3  GP"0*l*l$ 

fc  CHAN  3  GP  IS  fc  BUFF  3  GP  \% 

->  BUFF  3  GP  14<3>  ->  BUFF  3  GP  IS<4>  \ 
NCAN  1,2  AO  fc  CAN  3  GP  fc  SCP  3  G  P  *  0  "  I  *  1  S 

fc  CHAN  3  GP  2S  fc  BUFF  3  GP  2$ 

->  BUFF  3  GP  2$<3>  ->  BUFF  3  GP  2$<4>  i 
NCAN  1.2  AC  f.     NCAN  3  GP  fc  CAN  4  GP 

fc  SCP  4  G  P  A  1  S 

->  s<i>cp  4':gp-i$<2>; 

NCAN  1.2  AO  fc  NCAN  3  GP  fc  CAN  4  GP 
fc  SCP  4  GP*0*1*US  fc  BUFF  4  GP  1*$ 

~>*$<3>s< i>cp    4'  :gp* 1/M"US<2>    I 

NCAN  J.2  AO  fc  NCAN  3  GP  fc  CAN  4  GP 

fc     3CP     4     GP~OMAOS     fc     CHAN     4     GP     1$     fc     BUFF     4 

->  BUFF  4  GP  1$<3>  ->  BUFF  4  GP  1  *  S  <  4  >  i 
NCAN  1.2  AO  fc  NCAN  3  GP  fc  CAN  4  GP 

fc  £CP  4  GP  *0»1*0S  fc  BUFF  4  GP  1 

->*$<3>$<1  >CP  4'  :&PM'M'>G$<2>  ! 
NCAN  1.2  AC  fc  NCAN  3  GP  fc  CAN  4  GP 

fc  SCP  4  GP~n*l-OS 

fc  BUFF  4  GP  1  fc  CHAN  4  GP  2  5  fc  BUFF  4  GP  2-S 

->  BUFF  4  GP  2S<3>  ->  bUFF  4  GP  2A,5<4>  1 
NCAN  1.2  AO  fc  NCAN  3  GP  fc  CAN  4  GP 

fc    s  C P     4     G  P  *  0  -  1  *  1  °>    fc    t>\jyF     4    GP     1$    fc    BUFF     4    GP    2$ 

->     S«3>S<4>S<1>CP     4':GP*l*l*iS<2>     { 
NCAN     1,2     A  0     o     N  C  A  N     3     G  P     fc     CAN     4     G  P 

fc     5CP     4     GP-OMMS 

fc  CHAN  4  GP  IS  fc  BUFF  4  GP  1? 

-  >  BUFF  4  GP  1  S<3>  ->  BUFF  4  GP  I  S  <  4  >  | 
N  C  A  N  1  .  2  A  0  fc  NCAN  3  G  P  fc  CAN  4  G  P 

fc     SCP     4     GP-0A1M$ 

fc  CHAN  4  GP  2S  fc  BUFF  4  GP  2S 

->  BUFF  4  GP  2  $<3>  ->  BUFF  4  GP  2$<4>  J 
NCAN  1.2  AO  fc  NCAN  3  GP  fc  NCAN  4  GP 

fc  PROCESS  CP  1.2  AOS 

->  »  :PROCEc,S  CP  1.2  AO  S<1>  ( 
PHASE  2  fc  'JPROCESSi  -  >  PR0CESSS<1>  1 


GP  !■*$ 


fc  BUFF  4  GP  2*S 
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171  PHASE  3  0     SPROCESSs  ->  PR0CESSS<2>  J 

172  PHASE  2  ->  MODIFY  2} 

173  (7)  PHASE  2  fc  C$'  :PR$»PROCESS  ARM  DARM  CP  P  R  S  PR  AO  GP  *  0 

174  I  2  3  H    *C  *  3  '   START  MOVE  NEa  TEST  l  .  CHAM 

175  »  t»  '  :  SI  S2 

176  31  \~NEA\~CPCS»l  2.23A0sCPC\"*l  2  3  4Z3GPS':$ 

177  ->MODIFYS<l>NEh\A<3>GP->  MODIFY  2  J 

178  JPROCESSSPRM     PR'CSIS     ->     PRO  CE  SSS  <  1  >Pt<-0    PR'CS1$<2>     J 

179  |[\*U*8h  OAKH  CP  P  (i  S  (10  GP  »  0  1  2  3  4  'C  '3  .     '  a  SI  S2 

180  '    TEST  MOVE  NEW S 3 f S '  5 SS 1  $  ->  J  $ <2> '  I  $<3> \*< 1 > J < 1 >  I  S 1 S<4>  I 

l a i  i ! s* : $   ->    ;s<i >'  : t<2>    ; 

182  fPROCESSSPR'CO  N  E  ft  0  C  S  »  A  R  u  DARM  CP  P  R  S  AO  GP  CP  PR  ->  , 

183  0  1  2  3  4  'C  '3  '   TEST  MOVE  NEW  ' M  SI  S2 

184  8]| IS  ->  -START$<2>PR0CESSS<1>PR'CS<3>  I 

185  fPROCESS$PR'C\0  NElV\DCSt»AKM  DARM  CP  P  R  S 

186  AO  GP  »    o  1  2  3  4  'C  ' 3  '    .231$ 

187  -  >  *CHAN\D<1>PR  S"R     PRGCESSS<1> 

188  PR' CSTARTs<2>  !S<3>  I 

189  {PKOCESSSPR'CSTARTCSttARN  DARM  CP  P  R  S  AO  GP  * 

190  01234»C'3'.Sl  S223JS 

191  ->ASTARTs<2>PR0CESSS<l>PK'C$<3>  i 

192  !PROCESSSPR'C\A'ttfS 

193  ->  -CHAN\-<1>PR  S~S  PR0CESS$<l>PR'C4<2> f 

194  fPROCESSSPR'CO  MOVE\0CS«AKM  DARM  CP  P  R  S 

195  AO  GP  *  U  I  2  3  4  T .  '  3  '    .  %  3 .'  SS  I  \ "i '   3 

196  ->PK0CESS5<1>PR'C$<3>0  M0VE\0<l>$<2>.'Sl\A<l>S<4>'3  I 

197  [PROCESSSPR'CU  MOVE\OCPC$«1  2  .  S  3  A  0  C  $ 

198  «  »R«  DASH  CP  P  R  S  AO  GP  *  0  I  23  1 

199  '  C  '  J  '    .  2  3  .'  i  S  1  '  J 

200  ->-CHAn\0<  1  >PR  2*NEW  2  CP S < 2> AOS< 3> 

201  PR0CESSS<l>PR'C5<4>Sl$<2>»3  { 

202  fPR0CLSS$PR'C5C\Ai»R    S  s  3  •  $  S  I  5  '  3 

203  ->*CHANS<3>A0  R'-\-<l>PRoCESSS<l>PR*i;s<2>Sl'3  ! 

204  3  ->  $<1>PR?<2>  i 

2H5  PHASE  2  t,     CS'  1  AOSmPROCESS  ARM  DARM  P  R  S  CP  AO  GP  -  U  1 

206  2  3  4  *C  ♦ J  '   ' !  ' n     .  TEST 

207  2-SPROCESS  CPCSal  2  t  S  :  '  !  A  0  -  1  $  ->  PROCESS  CPS<2>' I  AO*  I  S<3>  ! 

208  PROCESS  CPCSttl  2  »z3':aOa1$  ->  PROCESS  CP S <  1  > '  1  AG *Q$< 2>  i 

209  3->S<l>A0s<2>i 

210  PHASE  2  i,     CS':C-P$  ttPROCESS  ARM  DARM  P  R  S  AO  GP  *  0  1 
21  1  TEST  CP234'C'J'    'tt  . 

212  2  -SPROCESSS'  :GPA1  i  ->  PROCE  SSS<2>  '  .«  GP  -  1  5  <  3>  I 

213  PROCESSS'  :GP"IS  ->  PR0CESSS<1>'  :GP-05<2>  i 

214  3->$<l>GP5<2>; 

215  (8)      PHASE  3  fc  SPROCESS  CPC%»1  2 

216  PHASE  3  t,    SPROCESS  CPCSul  2 

217  PHASE  3  £,  SPROCESS  CPCShI  2 

218  ->CAN  \"<1>GP  5 

219  PHASE  3  (,     SPROCESS  CPCSttl 

220  ->  NCAN  \«<l)  (iP  ; 

221  .    PHASE  3  h    -MOVESCPCSM  1  2  3  4  .23C\*nA0  GPZ3S 

222  ->  NCANS<2>\~< t >  ; 

223  PHASE  3  •>  NCAN  2  PR  i 

224  PHASE  3  i,    CHANCSa!  2  ,z3C\GPriA0  PR23\ —  S 

225  ->  CANS<1>\GP<1>  ->  NCANS<1>\GP<1>  i 

226  PHASE  3  6  C\~*CHAN  8UFFZ3  2  GP  1~4  b  SCP  2  GP"U*15AR,1  2  GP  IS 

227  ->  CAN  2  GP  ->  NCAN  2  G°  i 


.  S  3  A  0  -  1  4  -  >  CAN  $  <  2  >  A  0  i 
,  2  3  A  0  '•  0  $  ->  NCAN  l<2>  AC  | 
,23A0SCPC\*«1  2  3  423GP-1S 


2     ,5UA0$Crr\A(Jl     2     3     'ISJGP-OS 
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22a 

229 

230 

231 
232 
233 

234 
235 
236 
237 
238 
239 
240 
211 
242 
243 
244 
245 
246 
247 
248 
24? 
250 
251 
252 
253 
254 
255 
256 
257 
258 
259 
260 
261 
262 
263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 
274 
275 
276 
277 
278 
279 
200 
281 
282 
283 
284 
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PHASE  3  b     C\A«CHAN  8UFFZ3  2  GP  2A$  6  SCP  2  GPAUA1SARH  2  GP  2* 

->  CAN  2  GP  ->  NCAN  2  GP  I 
PHASE  3  b     C\~«CHAN  B  U  F  F  z  3  2  GP  3  A  S  6  $CP  2  GP~0A1SARH  2  GP  35 

->  CAN  2  GP  ->  NCAN  2  GP  I 
PHASE  3  b     C\-tiCHAN  BUFF233  GP  lAS  6  SCP  3  GP*0A1SARM  3  GP  1$ 

->  CAN  3  GP  ->  NCAN  3  GP  1 
PHASE  3  6  C\A«CHAN  BUFF  2 3  3  GP  2AS  6  SCP  3  GP"0A1SARM  3  GP  2$ 

->  CAN  3  GP  ->     NCAN  3  GP  I 
PHASE  3  b     C\~»CHAN  8UFF234  GP  1*$  6  SCP  4  GP"GA1SARM  4  GP  IS 

->  CAN  4  GP  ->  NCAN  4  GP  ( 
PHASE  3  6  C\~«CHAN  B  U  F  F  z  J  4  GP  2"%     b     SCP  4  GP->uA15ARM  4  GP  2  5 

->  CAN  4  GP  ->  NCAN  4  GP  I 
PHASE  3  b     '•CHAN  2  GP  l~SPROCESSS  b     SCP  2  GPA0AlSARM  2  GP  1$ 
6  L\"t*CHAN  BUFF232  GP  IS 

->  BUFF  2  GP  1A$<1>  ->  BUFF  2  GP  1$<6>  ? 
PHASE  3  6  "CHAN  2  GP  2ASPR0C£SSS  b     iCP  2  GP"0A1SARM  2  GP  2$ 

b     r\A«CHAN  3UFF2D2  GP  2$ 

->  BUFF  2  GP  2A$<1>  ->  BUFF  2  GP  2S<6>  1 
PHASE  3  b     ACHAN  2  GP  3A3PR0CESS$ 

b     SCP  2  GP"0AISARM  2  GP  3$  1  C\At»CHAN  BUFF232  GP  3S 

->  BUFF  2  GP  3  A  $  <  1  >  ->  BUFF  2  GP  3  5  <  6  >  1 
PHASE  3  b     "CHAN  3  GP  1APR0CE5SS 

b     $CP  3  GPAQA1SARM  3  GP  1$  6  C\"«CHAN  BUFF233  GP  IS 

->  BUFF  3  GP  1  A  S  <  I  >  ->  BUFF  3  GP  1  S  <  6  >  ; 
PHASE  3  b     "CHAN  3  GP  2APR0CESSS 

b     sCP  3  GP"0A1$ARM  3  GP  2$  &  C\A«CHAN  BUFFZ33  GP  2S 

->  BUFF  3  GP  2  A  S  <  1  >  -  >  BUFF  3  GP  2$<6>  5 
PHASE  3  b     "CHAN  4  GP  fSPRGCLSSS 

b     SCP  4  GP"0A1SARM  4  GP  IS  b     L\"rtCHAN  BUFFS  "J  4  GP  15 

->  BUFF  4  GP  1  A  $  <  1  >  -  >  BUFF  4  GP  1  5  <  6  >  } 
PHASE  3  b    "CHAN  4  GP  2"SPR0CES5$ 

b     SCP  4  GP"0"!  SARM  4  GP  25  b     C\AnCHAN  BUFF234  GP  2S 

->  DUFF  4  6  P  2  A  S  <  1  >  ->  BUFF  4  GP  2S<6>  i 
PHASE  3  b     "CHaN  2  GP  lA5PR0CESSS  b     SCP  2  GPA0A1SARH  2  GP  15 

->  CAN  2  GP  ->  NCAN  2  GP  5 
PHASE  3  b    "CHAN  2  GP  2ASPR0CESS$  b    SCP  2  &PACM5ARH  2  GP  2S 

->  CAN  2  GP  ->  NCAN  2  GP  i 
PHASE  3  b    "CHAN  2  GP  3ASPR0C£SS$  b    iCP  2  GPAOMSARM  2  GF  35 

->  (.AN  2  GP  ->  NCAN  2  GP  J 
PHASE  3  6  '-CHAN  3  GP  |*SPR0CeSS$  b     SCP  3  GP"OMSARM  3  GP  15 

->  CAN  3  GP  ->  NCAN  3  GP  ! 
PHASE  3  b    "CHAN  3  GP  2ASPR0CESSS  b     sCP  3  GPA0Al$ARM  3  GP  25 

->  CAN  3  GP  ->  NCAN  3  GP  ! 
PHASE  3  b    "CHAN  4  GP  i"4PR0CESSS  b    SCP  4  GP"0"lsARrt  4  GP  15 

->  CAN  H  GP  ->  NCAN  4  GP   ! 
PHASE  3  b     "CHAN  4  GP  2A5PR0CESSS  6  SCP  4  GP"0"1SARH  4  GP  25 

->     CAN  4  GP  ->  NCAN  4  GP  1 
PHASE  3  b     ACHANC\'t«  1  S  3GP\A5PK0CESSS 

-  >  CHAN\*<1>GP\"<2>S<1>  ->  CHAN\"<1>GP\"<.2>  1 
PHASE  3  b     K  I  L  L  r.  5 « '  C  '3  '    ARM  DARM  CP  P  R  S  AO  GP  "  . 
0  1  2  3  4  '  U 

ZSCPC\A\Aiil  2  3  4  AO  GPSJS  -> 

M0DIFY\A<l>\"<2>KILL  ->  MODIFY  2  J 

3  ->    : 

PHASE  3  b     "CHANCShI  2.63AOSPROCESSS  ->     BUFFS<;>A0S<2>  { 
PHASE  3  b     SPROCESS  CP  1.1  A0*0$  b     "CHAN  1,1  ACS 
- >  CAN  1,1  A  0  - >  NCAN  1,1  A  0  i 
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28S 
286 
267 
288 
28? 
290 
291 
292 
293 
294 
295 
296 
297 
298 
299 
300 
301 
302 
303 
304 
305 
306 
307 
308 


PHASE  3  6  SPR 

-  >  CAN  1,2 

PHASE  3  6  SPR 

6  CHAN  I  .  1 
->  CHAN  1  ,  1 

PHASE  3  6  SPR 

6  CHAN  1  .2 
->  CHAN  1  ,2 

PHASE  3  6  "CH 


JSPROCESSS 
PHASE  3  &  "ST 
PHASE  3  6  "CH 

->CHAN\*< 
PHASE  3  £,  "HO 

->  BUFF  7 
PHASE  3  0  "MO 
PHASE  3 
PHASE  3 


PHASE 
PHASE 


(.  "C\ 
6  *  N  E 

-0  NF. 
t,  "CH 
6  PRO 


OCESS  CP  1,2  AO-05  fc  "CHAN  1,2  AOS 

AO  ->  N  C  A  N  1,2  AO  ] 

OCESS  CP  1,1  A  0  M  $  6  "CHAN  1,1  AO  RSPROCESSS 

AO  RS 

ao  R$<s>s<3>  ->  Chan  1.1  ao  Rs<s>  i 

OCESS  CP  1,2  A  0  "  1  S  &  "CHAN  1,2  AO  R5PR0CE5SS 
AO  RS 

AQ  R$<S>S<3>  ->  CHAN  1,2  AO  RS<3>  J 
ANC$AO\"t>l  2  3  H  . 

2  1.1  A0\"  ->  .  AO  ,  { 
1  ,2  A0\"  ->  .  AO  ,   5 

->  CHAN$<1>A0\"<1>$<2>  ->  CHAN$<1>A0\"<1>J 
ARTsPROCESS  CP  2  PKS  ->  PK0CESSS<1>  J 
ANC\"B18  3PR\"$PK0CESS$ 

1>PR\"<2>S<1>  ->  CHAN\"<1>PR\"<2>  1 
VE\"CPCSt)l  2  .23ACS 

PR$<1>"0  M0VE\"<1>CP$<1>A0$<2>  i 
VE\"S  ->  PR0CESS$<1>  ; 

"  a  M  0  V  E  N  E  iV  8  3  $  ->  CAN  2  PR  ->  NCAN  2  PR  I 
ASPROCESS  CPCitti  2  .S3A0S  -  >  BUFF  2  P  R  S  <  2  > 

w  o  s  <  t  >  : 

ANSPROCESS  CPCSul  2  ,23A0S  ->  DUFF  2  PRS<2>  "  1 
CESS  CPCSM1  2  .23A05  ->  BUFF  2  PRS<1>"  ; 
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